I've since been convinced that Erik is right; that personalities
are the proper way to solve the problem.
>Neither one really works in the case of pid's. Once you move to
>a 32-bit pid in the kernel, there is nothing sensible one can
>return for getppid, when the parent's id is 100001.
>
>One could make a case for using personalities (discovered at exec
>time) for controling the pid range that a particular new process
>will be allocated to, and for using personalities for determining
>the pid range for fork. But the ppid case of new execing old
>would seem to be a show-stopper.
You are making it harder than it is.
There have been two major possibilities discussed as far as a 32-bit pid:
1 The 32-bit pid is constructed of a 16-bit pid and a 16-bit "other"
that might include tid or some clustering information.
2 The 32-bit pid makes for a more nearly unique pid between reboots.
The first possibility is easily dealt with; old binaries don't use threads
anyway, and aren't clustered apps, so their getpid() would return the low
16 bits, which is sufficient for these single-threaded apps.
The second possibility is decided a couple lines of kernel code at
most, and as no portable software will rely on a true 32-bit pid
space, it would be reasonable to make it a run-time option at what
value pids are wrapped.
People who value binary compatibility would leave the default of
32k, and those who want a large pid space change it to any value
that fits in 32 bits with sysctl or /proc/sys/.
Having separate pid spaces doesn't really work well; I can come up
with far more problems than exec.
michaelkjohnson
"Ever wonder why the SAME PEOPLE make up ALL the conspiracy theories?"