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

Re: sysctl.proc_exec_affinity to force launching of 32-bit flavor?
by Eric Gouriou 13 Mar '09

13 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Mar 12, 2009, at 5:54 AM, Jim Correia wrote: On Mar 12, 2009, at 6:10 AM, Terry Lambert wrote: For a drag and drop type install, LIPO isn't an option. In addition to the various solutions offered in this thread... 32b -mmacosx-version-min=10.4 64b -mmacosx-version-min=10.5 Eric _______________________________________________ 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… The place where this would be important today is on a machine capable of running 64 bit Intel binaries, but for which only the system framework is available, and not other frameworks. Since we changed the 64 bit binary cpu type number by adding a "has 64 bit frameworks bit" to it, when we added framework support, if you link a new binary, the 386 version of the binary is going to be preferred by the older version of the OS anyway, so you'd be solving a problem that doesn't exist in the first place. The other place it could be important is if you ported over your 32 bit KEXT or daemon that talked to it, and decide, for whatever reason that you wanted to still communicate ponter and long values between it and user space instead of using sized types. The other place where I wanted to control this is where my GUI app, which runs as a 32-bit process on Leopard (which can be influenced by LSMinimumSystemVersionByArchitecture), launches a helper (today via exec), and I'd like to run the helper as 32-bit on Leopard too, mainly because I don't want to be the reason the 64-bit frameworks are loaded in. But you could also LIPO at install time with your install tool or the binary itself when it saw the results of the uname(2) system call, or you could also write a small script to wrap the use of the arch(1) command, or you could use the posix_spawn(2) extensions documented in posix_spawnattr_setbinpref_np(2) to reexec yourself, if you didn't mind running the 64 bit binary, saying "whoops! I should be 32 bit!" and restarting yourself with a different preference. It looks like using posix_spawn solves the problem. (Previously I was using fork/exec because the code was originally written to target 10.4.x.) You can also consider building the various slices of your fat binary with different -mmacos-version-min settings so that, e.g., the 64bit slice will only be running on 10.5 while the 32bit slice is allowed on 10.4 . Adapt to taste. That's the theory at least, please double-check before committing to that solution. This email sent to site_archiver(a)lists.apple.com

1 0

State of ZFS & Java in Darwin, and suitability as server?
by Rick Mann 12 Mar '09

12 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Is there Java 1.6 for Darwin? Thanks in advance! -- Rick _______________________________________________ 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… Hi. I'm about to provision a 1U server for my little operation. I had been leaning toward Nexenta OS for its ZFS support, but because it's OpenSolaris under the hood, it's a little wonky (to me). It occurred to me that Darwin might be viable. Is anyone using open-source Darwin in a server environment? How is it working out? Are you able to use ZFS RAID-Z storage? Can you boot from ZFS? Although NexentaOS supports booting from ZFS, I don't think you can boot from a RAID-Z pool. I only have 4 drives to work with, and I'd like to put them all in a RAID-Z pool. Is it possible to boot from a read-only flash drive in Darwin, and put most of the OS onto a RAID-Z pool? This email sent to site_archiver(a)lists.apple.com

1 0

Re: sysctl.proc_exec_affinity to force launching of 32-bit flavor?
by Jonas Maebe 12 Mar '09

12 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 12 Mar 2009, at 13:54, Jim Correia wrote: You can use "arch" for this (man arch). Jonas _______________________________________________ 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… The other place where I wanted to control this is where my GUI app, which runs as a 32-bit process on Leopard (which can be influenced by LSMinimumSystemVersionByArchitecture), launches a helper (today via exec), and I'd like to run the helper as 32-bit on Leopard too, mainly because I don't want to be the reason the 64-bit frameworks are loaded in. This email sent to site_archiver(a)lists.apple.com

1 0

Re: sysctl.proc_exec_affinity to force launching of 32-bit flavor?
by Terry Lambert 12 Mar '09

12 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Mar 12, 2009, at 6:10 AM, Terry Lambert wrote: FWIW: -- Terry - Jim _______________________________________________ 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 Mar 12, 2009, at 5:54 AM, Jim Correia <jim.correia(a)pobox.com> wrote: The place where this would be important today is on a machine capable of running 64 bit Intel binaries, but for which only the system framework is available, and not other frameworks. Since we changed the 64 bit binary cpu type number by adding a "has 64 bit frameworks bit" to it, when we added framework support, if you link a new binary, the 386 version of the binary is going to be preferred by the older version of the OS anyway, so you'd be solving a problem that doesn't exist in the first place. The other place it could be important is if you ported over your 32 bit KEXT or daemon that talked to it, and decide, for whatever reason that you wanted to still communicate ponter and long values between it and user space instead of using sized types. The other place where I wanted to control this is where my GUI app, which runs as a 32-bit process on Leopard (which can be influenced by LSMinimumSystemVersionByArchitecture), launches a helper (today via exec), and I'd like to run the helper as 32-bit on Leopard too, mainly because I don't want to be the reason the 64-bit frameworks are loaded in. For a drag and drop type install, LIPO isn't an option. If it knows enough to know that it wants to exec a lower graded binary slice of itself, it could lipo and exec just as easily as it could do the specific exec of the lower graded slice from the higher graded slice. Another alternative is a small helper program that is pointed to by the plist that repoints it at either the 32 or 64 bit binary rather than itself the first time it's run, thus avoing the overhead on subsequent runs. The only place a first-time-you-run approach isn't appropriate is if you are loading off network storage shared between systems with conflicting requirements (unlikely for KEXTs, but possible). A small helper binary that sticks around rather than repointing things and execs daemon32 or daemon64 as appropriate still works for that case, though. But you could also LIPO at install time with your install tool or the binary itself when it saw the results of the uname(2) system call, or you could also write a small script to wrap the use of the arch(1) command, or you could use the posix_spawn(2) extensions documented in posix_spawnattr_setbinpref_np(2) to reexec yourself, if you didn't mind running the 64 bit binary, saying "whoops! I should be 32 bit!" and restarting yourself with a different preference. It looks like using posix_spawn solves the problem. (Previously I was using fork/exec because the code was originally written to target 10.4.x.) This email sent to site_archiver(a)lists.apple.com

1 0

Re: sysctl.proc_exec_affinity to force launching of 32-bit flavor?
by Eli Bach 12 Mar '09

12 Mar '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=SGOFkfJb0mBYQorIJjBShF36T5BSnHvK21nBEFqfNHc=; b=dBuiWeqhplD4UD0bcM8Jm1NMpm8Ol2dOzEHVrlOfSXxmYviVAQSz+GFYxwBtDPjUFY VRagkfZ/i4quc4D+FMl3cRciG2lxTphygpQWl0ak41vuTH6pIIxht+y/TmpDNLacwJ3j ews/aOE0OX1ceR9/jwoJ92cJpaucgjtaPKuPU= 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=XbdseOMDFSEBYZJhcPLkH9aiLtmUZ4iLgoxpIxkqm2QOExwddAhHYcTKt4ZRCtLtJy GkhKLiARxsgFKRrLtKZTmp+A0MhXjWRQVL5Ce00stW2+2HbmFRT1E8XqlQoKTFG9AowD qG1fwpmWb9GnwttYH+dAX0gO2jxYwAVYxlhPo= On Mar 12, 2009, at 5:54 AM, Jim Correia 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… The other place where I wanted to control this is where my GUI app, which runs as a 32-bit process on Leopard (which can be influenced by LSMinimumSystemVersionByArchitecture), launches a helper (today via exec), and I'd like to run the helper as 32-bit on Leopard too, mainly because I don't want to be the reason the 64-bit frameworks are loaded in. For a drag and drop type install, LIPO isn't an option. If you really want to do this, you could just ship two executables for your helper tool in your bundle. One ppc/32-bit intel, and a 64-bit intel. Then you only have to code for some mythical future system where you test if it supports 64-bit intel, and exec the 64-bit intel executable, else exec the combo executable. This email sent to site_archiver(a)lists.apple.com

1 0

Socket recv behaviour in real-time context
by Stéphane Letz 12 Mar '09

12 Mar '09

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com Hi, Thanks. Stephane Letz We are using UDP sockets to transmit audio in real-time between 2 machines. Basically the "master" machine is synchronized on the audio interrupt and send/recv audio packets on the "slave" machine. The "slave" machine is synchronized on incoming packets (that is waiting for an incoming packet on the socket to start it's audio cycle). The "slave" machine reception thread is set-up in real-time mode (using thread_policy_set /THREAD_TIME_CONSTRAINT_POLICY kind of API). It works quite reliably until we start to load the slave machine (like starting a big compilation). In this case the RT slave thread does not "wake up" the the right time, and we have quite big latencies (up to 50 millisecond latency measured on a MacPro Intel 4 cores 10.5.6 when the audio cycle is supposed to be 5 millisecond). More precisely it seems the socket recv operation blocks a lot of time. We configure the socket with SO_SNDBUF/SO_RCVBUF and possibly SO_RCVTIMEO kind of options. The same code works without problem on Linux. Are they special socket options to add in this case on OSX? is this an known problem for sockets on OSX? _______________________________________________ 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: sysctl.proc_exec_affinity to force launching of 32-bit flavor?
by Jim Correia 12 Mar '09

12 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Mar 12, 2009, at 6:10 AM, Terry Lambert wrote: For a drag and drop type install, LIPO isn't an option. - Jim _______________________________________________ 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… The place where this would be important today is on a machine capable of running 64 bit Intel binaries, but for which only the system framework is available, and not other frameworks. Since we changed the 64 bit binary cpu type number by adding a "has 64 bit frameworks bit" to it, when we added framework support, if you link a new binary, the 386 version of the binary is going to be preferred by the older version of the OS anyway, so you'd be solving a problem that doesn't exist in the first place. The other place it could be important is if you ported over your 32 bit KEXT or daemon that talked to it, and decide, for whatever reason that you wanted to still communicate ponter and long values between it and user space instead of using sized types. The other place where I wanted to control this is where my GUI app, which runs as a 32-bit process on Leopard (which can be influenced by LSMinimumSystemVersionByArchitecture), launches a helper (today via exec), and I'd like to run the helper as 32-bit on Leopard too, mainly because I don't want to be the reason the 64-bit frameworks are loaded in. But you could also LIPO at install time with your install tool or the binary itself when it saw the results of the uname(2) system call, or you could also write a small script to wrap the use of the arch(1) command, or you could use the posix_spawn(2) extensions documented in posix_spawnattr_setbinpref_np(2) to reexec yourself, if you didn't mind running the 64 bit binary, saying "whoops! I should be 32 bit!" and restarting yourself with a different preference. It looks like using posix_spawn solves the problem. (Previously I was using fork/exec because the code was originally written to target 10.4.x.) This email sent to site_archiver(a)lists.apple.com

1 0

Display Controller.
by Sachin Kumar 12 Mar '09

12 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.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

Display Controller
by Sachin Kumar 12 Mar '09

12 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.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: sysctl.proc_exec_affinity to force launching of 32-bit flavor?
by Terry Lambert 12 Mar '09

12 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Suppose I have a binary built with ppc, i386 and x86_64 architectures. -- Terry _______________________________________________ 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 Mar 11, 2009, at 11:36 PM, Jim Correia wrote: Also suppose that on a particular OS release, I want to ensure that when I exec that binary, the i386 variant runs, not the x86_64. For bundled applications, I can influence this through the LS keys. Before I exec the tool, I've tried setting sysctl.proc_exec_affinity to CPU_TYPE_X86 but the 64-bit version is executed. (Setting the affinity to ppc seems to work.) Am I overlooking something? Yeah, the affinity sysctl was a kluge that worked due to single threading of forks from finder, and it also dealt with child binaries preferences being inherited from the parent process through multiple children and grandchildren. It was primarily intended to programs which had PPC versions of plugins for which there were not yet any Intel equivalents. It wasn't really possible for the approach to be reasonably generalized to arbitrary architectures, both because it really failed to support the ideas necessary for that, and because Moores law is no longer a law. The place where this would be important today is on a machine capable of running 64 bit Intel binaries, but for which only the system framework is available, and not other frameworks. Since we changed the 64 bit binary cpu type number by adding a "has 64 bit frameworks bit" to it, when we added framework support, if you link a new binary, the 386 version of the binary is going to be preferred by the older version of the OS anyway, so you'd be solving a problem that doesn't exist in the first place. The other place it could be important is if you ported over your 32 bit KEXT or daemon that talked to it, and decide, for whatever reason that you wanted to still communicate ponter and long values between it and user space instead of using sized types. But you could also LIPO at install time with your install tool or the binary itself when it saw the results of the uname(2) system call, or you could also write a small script to wrap the use of the arch(1) command, or you could use the posix_spawn(2) extensions documented in posix_spawnattr_setbinpref_np(2) to reexec yourself, if you didn't mind running the 64 bit binary, saying "whoops! I should be 32 bit!" and restarting yourself with a different preference. This email sent to site_archiver(a)lists.apple.com

1 0