On Tue, Mar 14, 2006 at 11:43:38AM -0700, 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.
hmm ... not sure about that, what 'we' need is a way
to move between pid spaces and to control processes
in a child space from the parent process ...
nevertheless I don't think we have a problem with
schizophrenic processes if they have a somewhat sane
*G* interface/view into both spaces ...
> To allow for migration it must be possible for the pids in
> those pid spaces to be different.
I take that as migration of a 'container' from one
system to another, not as 'migration' between spaces
I don't understand what you mean here, please elaborate
> 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?
again, for what would I need a 'second' or 'third' pid
value for a process either on demand or permanent for
handling or migration?
> I assume most processes by default only have a pid value in
> a single pid space.
>
> The reason I ask is that I believe I know how to implement
> a cheap general mechanism for adding additional pids to a
> process.
I have the feeling this is going into a completely wrong
direction, what am I missing here?
TIA,
Herbert
> Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
