[lkml]   [2006]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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.


> 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.


> 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-03-14 21:35    [W:0.049 / U:5.156 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site