Messages in this thread | | | Date | Tue, 14 Mar 2006 21:32:41 +0100 | From | Cedric Le Goater <> | Subject | Re: question: pid space semantics. |
| |
Eric W. Biederman wrote:
> To retain any part of the existing unix process management > we need some processes that show up in multiple pid spaces.
yep.
> To allow for migration it must be possible for the pids in those pid > spaces to be different.
agree, the process that creates a pidspace is in different pidspaces if you want to maintain the process hierarchy.
> It is undesirable in the normal case of affairs to allocate more > than one pid per process.
yes.
> Given the small range of pid values these constraints make an > efficient and general pid space solution challenging. > > The question: > If we could add additional pid values in different pid spaces to a > process with a syscall upon demand would that lead to an > implementation everyone could use?
I don't know yet if we would use it but we need it :) One way of the other. The creator of a pidspace could be the parent of multiple pidspaces and hence it needs multiples pids, one in each pidspace.
Could that be done with the syscall creating the pidspace ? because it seems that the process creating a pidspace is the only candidate ?
> [ ... ] > > The reason I ask is that I believe I know how to implement a cheap > general mechanism for adding additional pids to a process.
OK good. That's what we need to begin with : something cheap to prove the feature is useful.
We have already implemented the vpid in a very similar way to the openvz team, although with less optimization and linux feeling. Both efforts and yours, on pidspaces, didn't prove to be good enough to be valuable.
C. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |