Messages in this thread | | | Subject | Re: [RFC][PATCH 0/20] Multiple instances of the process id namespace | From | (Eric W. Biederman) | Date | Mon, 06 Feb 2006 13:51:41 -0700 |
| |
Hubertus Franke <frankeh@watson.ibm.com> writes:
>> From the kernel community at large I am asking: >> Does the code look generally sane? > > Yes, but I have one question for you... > Large parts of the patch are adding the pspace argument > to find_task_by_pid() and in many cases that argument is > current->pspace. > It might bring down the size of the patch if you > have > > find_task_by_pid( pid ) { return find_task_pidspace_by_pid ( current->pspace, > pid ); } > > and then only deal with the exceptional cases using find_task_pidspace_by_pid > when the pidspace is different..
That is a possibility. However I want to break some eggs so that the users are updated appropriately. It is only by a strenuous act of will that I don't change the type of pid,tgid,pgrp,session.
The size of the changes is much less important than being clear. So for I want find_task_by_pid to be an absolute interface.
>> Does the use of clone to create a new namespace instance look >> like the sane approach? >> > > At he surface it looks OK .. how does this work in a multi-threaded > process which does cloen ( CLONE_NPSPACE ) ? > We discussed at some point that exec is the right place to do it, > but what I get is that because this is the container_init task > we are OK ! > A bit clarification would help here ...
Well the parent doesn't much matter. But the child must have a fresh start on all the groups of processes. As all other groupings known by a pid are per pspace, so they can't cross that line.
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/
| |