July 2009 - Darwin-dev - lists.apple.com

ASL issue
by Santosh Sinha 31 Jul '09

31 Jul '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi List, Thanks Santosh _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… i am using Mac OS 10.5.7 and i am writing the error data in the asl log file, but after three day my data is automatically flushed from my system its possible. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Mac OS X Jails
by Brian Mastenbrook 31 Jul '09

31 Jul '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Jul 30, 2009, at 10:16 PM, Amanda Walker wrote: _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… chroot() does not instantiate multiple copies of the OS. Not in and of itself, no, which is why I then talked about how to create a chroot without actually having to make a separate copy of the OS. However, the best method I could determine to do that involved hardlinks, and it didn't seem to provide the isolation that the OP wanted. If you actually copy a portion of the Apple Software into your chroot and then run it, you are running a separate copy of the a portion software, and thus I can't see how it's any different from what VMware does. There is no specific anti-virtualization provision in the license. The license specifically states that you have no rights to the software except those granted by Apple, and that Apple only grants you the right to use and run one copy of the software at a time. This is the provision that Apple believes prohibits virtualization. Given the wording and this interpretation, I can't see how running a copied portion of the software without creating a separate instance of the kernel is any different, as the license doesn't address such subtleties. I'm not *trying* to be absurd here, except inasmuch as I've twisted my thinking into the right shape to conform to what Apple believes their agreement allows. Once I've done that, I can't really see a difference between different forms of copying and running a portion of the Apple Software at the same time. If you think there is a difference, I'd love to hear your reasoning. For what it's worth, I wouldn't be kept up at night by doing this. I lost my license to use OS X when I made two backup copies of my hard drive, and have been running without a license ever since. So far as I'm aware, this hasn't yet caused the end of the world. -- Brian Mastenbrook brian(a)mastenbrook.net http://brian.mastenbrook.net/ This email sent to site_archiver(a)lists.apple.com

1 0

Re: Sending SCSI commands in Mac OS X
by rohan a 31 Jul '09

31 Jul '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xPi9v9crovBvuGwqdxJT/aGwpIOd0vbxN3CClu0a5z8=; b=hhCnYUB3D1juN51NrLojMKBG1wgHKEJc3sjLUS+qfGJ8rFV4YPYsIp0afbf3XhMRF2 djXd6QNjAaaMvuid4CmIatUAAuqPkoi2+9ldnFROhV+hB3pO5NVWprQp9hbYTATEL/69 FobQ3eUJcxmRHrli1XFcAEdnTveXL+C2OJTpU= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tZENpU1z4eaODy8epmS4NEZr1i3LOqY1Js5fHY0dZ1fqr67ceM0bl0XVpOhx/P+FJi UOd3P47DHg7lcKduPbu5xmoV6NuDha5Q0osX3LVfEsYnKTYbbcTXn/nzNFHD58+uwYZI l62RbsAUrF3YoGztphWPqSpIuhGnIv3qt4az4= Hi, WorkingwithSAM.pdf also states that: $00 for block storage devices that comply with the SCSI block commands specification $05 for multimedia devices that comply with the SCSI multimedia commands specification $07 for magneto-optical devices that comply with the SCSI block commands specification $0E for reduced block command devices that comply with the SCSI reduced block commands specification Now how do I check if a device falls in a particular category. Is there anyway I know that a device is $00,05,07 or 0E ? Also, I see that SCSI commands require SCSITaskDeviceInterface **interface ex: void Inquiry(SCSITaskDeviceInterface **interface) On looking further I see this: interface = ( *mmcInterface )->GetSCSITaskDeviceInterface ( mmcInterface ); But this is only for MMCDevice Interface. What about SCSI devices? Thanks On 7/24/09, mlists(a)ugsoft.de <mlists(a)ugsoft.de> wrote: > > Am 24.07.2009 um 05:55 schrieb Terry Lambert: > > > Since no one else posted... > > > > Apparently the last machine I used had your tools installed on, which > generated BSD device stubs for my QIC tape drive when I plugged it it. 8-). > > > > Ok. What we are doing with our tools is to create pseudo device files in > /etc/UGSdev, e.g. /etc/UGSdev/nst0, which can be passed as remote devices > (e.g. 127.0.0.1:/etc/UGSdev/nst0) to command line tools such as tar, xtar, > dump/restore, mt, etc., so that our rmt will communicate with the SCSI, > FireWire, USB and FibreChannel tape/changer devices. Please take a look at > http://www.ugsoft.de/intl/faq.html#xtarntape for more > information on that. > > For those who are interested: > The tools esbdump, esbrestore, esbmt, rmt and the smtc tape device "driver" > are free to use and are included in ES-Backup > http://www.ugsoft.de/intl/esbackup . No registration nor > activation keys required to use the shell commands. See included License > document. Since no source code is included one won't be able to learn how to > do the SCSI programming on OS X, though. In addition to the functionality of > the corresponding Unix tools such as the standard dump tape format, our > tools offer support for Mac OS X file attributes, resource forks, etc., as > well as direct tape positioning during restore which make them usefull for > today's large amounts of backup data. Also, these tools are used in our > commercial product ES-Backup on Mac OS X Intel and PPC, Solaris SPARC and > x86, Linux x86 - but this is off-topic. > > > > > > The officially supported interface is SCSITaskDeviceInterface, from a user > client. Sorry for the confusion. > > > > I thought I've missed something ;-) > > Uwe > > > > > > Rohan: This means "no, you can not use an ioctl". > > > > -- Terry > > > > On Jul 23, 2009, at 7:04 AM, mlists(a)ugsoft.de wrote: > > > > > Am 23.07.2009 um 13:26 schrieb Terry Lambert: > > > > > > > Did you go to <http://developer.apple.com> and read the document "SCSI > Architecture Model Device Interface Guide"? > > > > > > > > It states: > > > > > > > > "By design, Mac OS X does not allow applications to send SCSI or ATA > commands to storage devices unless the application developer also provides > an in-kernel device driver that supports the commands." > > > > > > > > One of the intents if this is to allow the driver to model state for > such coomands such that the state if the device is known to the driver at > all times. > > > > > > > > For standard tape devices, you should not need to write your own > driver; if you plug the device in, it will show up in /dev, > > > > > > > > > > Never seen a tape drive, neither SCSI, FireWire, USB nor FibreChannel > connected to Mac OS X 10.2 up to 10.5 which shows up in /dev. What device > filename should I look for? > > > > > > > > > > and you can at least issue reads, writes, and standard commands, such > as causing a rewind, via the device file. For non-standard commands, such as > you would use to control loading and unloading tapes in a tape robot, etc., > you will need to write an in-kernel driver that knows how to talk to the > hardware and subclasses the more generic device (i.e. the IOKit model lets > you write only the missing pieces implementing the missing control commands; > you don't write a whole driver that implements read/write/etc.). > > > > > > > > > > Instead we use SCSITaskDeviceInterface functions from userland as > described in Apple's SCSI Architecture Model Device Interface Guide > "WorkingWithSAM.pdf" in order to implement a "SCSI pass-thru" functionality. > No additional driver required. > > > > > > > > > Uwe > > > > > > > > > > > > > > > On 7/24/09, mlists(a)ugsoft.de <mlists(a)ugsoft.de> wrote: > > Am 24.07.2009 um 05:55 schrieb Terry Lambert: > > > Since no one else posted... > > > > Apparently the last machine I used had your tools installed on, which > generated BSD device stubs for my QIC tape drive when I plugged it it. 8-). > > > > Ok. What we are doing with our tools is to create pseudo device files in > /etc/UGSdev, e.g. /etc/UGSdev/nst0, which can be passed as remote devices > (e.g. 127.0.0.1:/etc/UGSdev/nst0) to command line tools such as tar, xtar, > dump/restore, mt, etc., so that our rmt will communicate with the SCSI, > FireWire, USB and FibreChannel tape/changer devices. Please take a look at > http://www.ugsoft.de/intl/faq.html#xtarntape for more > information on that. > > For those who are interested: > The tools esbdump, esbrestore, esbmt, rmt and the smtc tape device "driver" > are free to use and are included in ES-Backup > http://www.ugsoft.de/intl/esbackup . No registration nor > activation keys required to use the shell commands. See included License > document. Since no source code is included one won't be able to learn how to > do the SCSI programming on OS X, though. In addition to the functionality of > the corresponding Unix tools such as the standard dump tape format, our > tools offer support for Mac OS X file attributes, resource forks, etc., as > well as direct tape positioning during restore which make them usefull for > today's large amounts of backup data. Also, these tools are used in our > commercial product ES-Backup on Mac OS X Intel and PPC, Solaris SPARC and > x86, Linux x86 - but this is off-topic. > > > > > > The officially supported interface is SCSITaskDeviceInterface, from a user > client. Sorry for the confusion. > > > > I thought I've missed something ;-) > > Uwe > > > > > > Rohan: This means "no, you can not use an ioctl". > > > > -- Terry > > > > On Jul 23, 2009, at 7:04 AM, mlists(a)ugsoft.de wrote: > > > > > Am 23.07.2009 um 13:26 schrieb Terry Lambert: > > > > > > > Did you go to <http://developer.apple.com> and read the document "SCSI > Architecture Model Device Interface Guide"? > > > > > > > > It states: > > > > > > > > "By design, Mac OS X does not allow applications to send SCSI or ATA > commands to storage devices unless the application developer also provides > an in-kernel device driver that supports the commands." > > > > > > > > One of the intents if this is to allow the driver to model state for > such coomands such that the state if the device is known to the driver at > all times. > > > > > > > > For standard tape devices, you should not need to write your own > driver; if you plug the device in, it will show up in /dev, > > > > > > > > > > Never seen a tape drive, neither SCSI, FireWire, USB nor FibreChannel > connected to Mac OS X 10.2 up to 10.5 which shows up in /dev. What device > filename should I look for? > > > > > > > > > > and you can at least issue reads, writes, and standard commands, such > as causing a rewind, via the device file. For non-standard commands, such as > you would use to control loading and unloading tapes in a tape robot, etc., > you will need to write an in-kernel driver that knows how to talk to the > hardware and subclasses the more generic device (i.e. the IOKit model lets > you write only the missing pieces implementing the missing control commands; > you don't write a whole driver that implements read/write/etc.). > > > > > > > > > > Instead we use SCSITaskDeviceInterface functions from userland as > described in Apple's SCSI Architecture Model Device Interface Guide > "WorkingWithSAM.pdf" in order to implement a "SCSI pass-thru" functionality. > No additional driver required. > > > > > > > > > Uwe > > > > > > > > > > > > > > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Mac OS X Jails
by Mo McRoberts 31 Jul '09

31 Jul '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Fri, Jul 31, 2009 at 03:00, Bill Northcott<w.northcott(a)unsw.edu.au> wrote: > At runtime other systems search some sort of shared library path to find an > appropriate library to link. Darwin is different. Most ELF systems can (and regularly do) encode the load-path into the binaries. If you're using GNU libtool, the -R<path> (if memory serves) link-time flag is translated into the appropriate link-time magic, although I must confess I prefer Mach-O's mechanism. While it may well be true that in this case Juan doesn't need jails in order to accomplish his requirements, that isn't to say that a) they're not useful, and b) existing facilities provide the same functionality, because they don't. jails are one of the relatively few features of FreeBSD that Darwin lacks. M. -- http://nevali.net _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Mac OS X Jails
by Clark Cox 31 Jul '09

31 Jul '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vJsonORNn4D9LiD/EcFNXSRWaAXLejNzYPS4Bbhekyg=; b=XGSAGkUMbdsOW0Md/GomnvknQ2DNgVoNeOm6cmJ8R2KSCtD31AbB2IIfYma5i4/5Fb EvqVbMZb/NjIyuVc2cuLiH3YOH7+57Wue/r9UuZ7R3P0BFBpCW6nh4VHpeKA5cSj3GV1 pH158V6tGsDPPTDUsI6MqWZP64GqBbHefs5FA= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=weiS91Kmb0ZTZPI9zM5ggGgPXLY9TeyuRZEJMu7PvknGWs3bsBu5fWAEZnoJvDVjLG aciQAQxzMTmU0t+MQftqLoLuaMckMoteK7C7vts0O7zLeSAnRJ6S1YpZeYaMvOosQ8ce a8WmQUdipjWdT//E2t9dC/ovdNOU6BgisEqWk= On Thu, Jul 30, 2009 at 12:49 PM, Brian Mastenbrook<brian(a)mastenbrook.net> wrote: > On Jul 30, 2009, at 1:45 PM, Terry Lambert wrote: > >> Given your description of your problem space, you don't need partitioning >> of additional resource namespaces for security reasons, so you could simply >> use chroot instead and handle it as a filesystem/security identifier >> namespace issue. > > IANAL, but if you do decide to go down this route keep in mind that from a > license perspective chroot is the same as virtualization, Huh? chroot() is nothing like virtualization. In no way does it involve running (or even installing) multiple copies of the OS. With that in mind, the rest of your post is moot. -- Clark S. Cox III clarkcox3(a)gmail.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Mac OS X Jails
by Bill Northcott 31 Jul '09

31 Jul '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 31/07/2009, at 12:25 PM, Juan Madrigal wrote: The zealots might disagree with me, but if you want BSD, just use it! Bill _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com Not a linux fan ;) I am really fairly indifferent at the OS level. I find fun in the higher level software. I prefer the BSD's. Though Solaris, AIX, and z/OS are quite interesting. Sticking to what you know well usually works best in my experience. I'm talking about running for example apache PHP, Perl in its own jailed environment so they think they are in their on box. Jails duplicate the root or specified directory structure and isolates whatever is running in it from everything else and I can assign resources to it Unless there's another way to replicate this. I'm going to just use FreeBSD. smime.p7s

1 0

Re: Mac OS X Jails
by Amanda Walker 31 Jul '09

31 Jul '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com --Amanda _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On Jul 30, 2009, at 3:49 PM, Brian Mastenbrook wrote: IANAL, but if you do decide to go down this route keep in mind that from a license perspective chroot is the same as virtualization, which is not allowed for non-server versions of OS X [1]. If you violate this condition of the license, your license to use that copy of OS X is automatically terminated, and you must destroy your copies of the software. chroot() does not instantiate multiple copies of the OS. It is in no sense like virtualization, and has no license implications. As I said, I'm not a lawyer; I'm simply going on Apple's own interpretation of the license agreement as forbidding VMware to virtualize client versions of OS X. Which has nothing to do with (or in common with) using chroot() to run, for example, multiple copies of Apache with different config files. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Mac OS X Jails
by Eli Bach 31 Jul '09

31 Jul '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:subject :mime-version:date:references:x-mailer; bh=dZTPwBWMQmvbeaC5CqX9AXTEzNQW2Eeagzw+9JEWxtI=; b=LNCfD4uqJ4qCSxvh+eGV1GjZH8CGtFtTHl+Gs/EOehJKbVQal/s6ShEx8hbFrYB2Cy ApJb9qnbb08z7onKmrZfxHVfItnYNhU0SGsQgU4oCyadogFvDSc8mcSVGNQRblGrlFuq peDAxW6mWRVyA2SUjaEZrIyEpR0HuklKi7RDY= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:subject:mime-version:date:references :x-mailer; b=sBYjFbuq+AS6DjlpYLMXRVm7++UpK8X0OU0+tw4DcLmd4RRX8eTt1RA6cE2+57W+zV gNzAuipyjz+MXNCAXelm0ytBrn40VLFtYmtJDz4zRfjo0gBnaFq1eIZuchAC4Zg+X7zl HDy4nwNrqn/GUq1RuTG0j9zyjLc/4DFwIGCsI= On Jul 30, 2009, at 3:39 PM, z3r0_f4ct0r(a)mac.com wrote: Eli _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… For now I think its best that I setup a FreeBSD server with the appropriate jailed environments and connect to it to get work done. Another solution that MAY work, would be to use the free VirtualBox software. I'm not sure if it lets you run multiple vm's at a time, but even if not, you could run just one instance of Linux/somebsd with your Jail support... This email sent to site_archiver(a)lists.apple.com

1 0

Re: Mac OS X Jails
by Juan Madrigal 31 Jul '09

31 Jul '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Not a linux fan ;) I prefer the BSD's. Though Solaris, AIX, and z/OS are quite interesting. -Juan On Jul 30, 2009, at 10:00 PM, Bill Northcott wrote: Horror horror horror: Darwin/MacOS is NOT Linux. Get used to it! ;-) So you see jails are not there, because you don't need them. Hope that helps you not to go off on some wild goose chase. Bill Northcott _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I'm talking about running for example apache PHP, Perl in its own jailed environment so they think they are in their on box. Jails duplicate the root or specified directory structure and isolates whatever is running in it from everything else and I can assign resources to it Unless there's another way to replicate this. I'm going to just use FreeBSD. On 31/07/2009, at 5:03 AM, Juan wrote: I need to set up multiple development environments on my Macbook Pro and don't want to trash the default Mac OS X installs of apache etc... A Jail would simplify things considerably. I hope Mac OS X ports over FreeBSD Jails or Solaris Zones as soon as possible! Its sorely needed. Parallels or VMWare is over kill and resource intensive. Jails are lightweight. I really can't believe Jails aren't in Mac OS X. What a shock! That does not mean you cannot do what you you are trying to do. It just means you might need to think different. The big difference between Darwin and all the other UNIXen that I have used: Linux, Solaris, HP-UX, True64..., is in the shared library arrangement. At runtime other systems search some sort of shared library path to find an appropriate library to link. Darwin is different. The path to the linked shared libraries is written into an executable at static link time. At runtime, dyld (the launcher) will always look at that path first. It only uses the DYLD_LIBRARY_PATH if the library is not found at the right path. (do an 'otool -L' on any library or executable) So you can have as many virtual systems as you like, build and run using them and almost the only thing they need in common is the kernel (and maybe some GUI stuff if you use it). Look at the way Xcode uses SDKs and the systemroot and other useful compiler and linker options. (the linker is very different RTFM) This email sent to site_archiver(a)lists.apple.com

1 0

Re: Mac OS X Jails
by Bill Northcott 31 Jul '09

31 Jul '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Horror horror horror: Darwin/MacOS is NOT Linux. Get used to it! ;-) So you see jails are not there, because you don't need them. Hope that helps you not to go off on some wild goose chase. Bill Northcott _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com On 31/07/2009, at 5:03 AM, Juan wrote: I need to set up multiple development environments on my Macbook Pro and don't want to trash the default Mac OS X installs of apache etc... A Jail would simplify things considerably. I hope Mac OS X ports over FreeBSD Jails or Solaris Zones as soon as possible! Its sorely needed. Parallels or VMWare is over kill and resource intensive. Jails are lightweight. I really can't believe Jails aren't in Mac OS X. What a shock! That does not mean you cannot do what you you are trying to do. It just means you might need to think different. The big difference between Darwin and all the other UNIXen that I have used: Linux, Solaris, HP-UX, True64..., is in the shared library arrangement. At runtime other systems search some sort of shared library path to find an appropriate library to link. Darwin is different. The path to the linked shared libraries is written into an executable at static link time. At runtime, dyld (the launcher) will always look at that path first. It only uses the DYLD_LIBRARY_PATH if the library is not found at the right path. (do an 'otool -L' on any library or executable) So you can have as many virtual systems as you like, build and run using them and almost the only thing they need in common is the kernel (and maybe some GUI stuff if you use it). Look at the way Xcode uses SDKs and the systemroot and other useful compiler and linker options. (the linker is very different RTFM) smime.p7s

1 0