![]() | |||||||||||||
Messages in this thread |
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/ | ||||||||||||
| Last update: 2006-03-15 07:05 [from the cache] ©2003-2008 | |||||||||||||