[lkml]   [2006]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: question: pid space semantics.
Herbert Poetzl <> writes:

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

The conditional was this is what it takes to reuse the existing

> 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

Basically that in the general case there can be no assumptions
that a pids in one pid space do not conflict with pids in another pids

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

Not for migration for things such a ptrace, ioprio, granting of
capabilities or any of the kernel's management operations

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-15 07:05    [W:0.152 / U:0.108 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site