Re: question: pid space semantics.

[Cedric Le Goater <clg@fr.ibm.com>]

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.