Re: sysctl.proc_exec_affinity to force launching of 32-bit flavor?
Re: sysctl.proc_exec_affinity to force launching of 32-bit flavor?
- Subject: Re: sysctl.proc_exec_affinity to force launching of 32-bit flavor?
- From: Terry Lambert <email@hidden>
- Date: Thu, 12 Mar 2009 03:10:25 -0700
On Mar 11, 2009, at 11:36 PM, Jim Correia wrote:
Suppose I have a binary built with ppc, i386 and x86_64 architectures.
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.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden