Messages in this thread | | | Subject | Re: question: pid space semantics. | From | (Eric W. Biederman) | Date | Tue, 14 Mar 2006 23:01:51 -0700 |
| |
Herbert Poetzl <herbert@13thfloor.at> 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 interfaces.
> 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
Yes.
> 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 space.
>> 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
Eric - 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/
| |