Messages in this thread | | | Date | Mon, 06 Feb 2006 16:07:04 -0500 | From | Hubertus Franke <> | Subject | Re: [RFC][PATCH 0/20] Multiple instances of the process id namespace |
| |
Eric W. Biederman wrote: > Hubertus Franke <frankeh@watson.ibm.com> writes: > > >>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. >
Fair enough, valid answers .. I checked the patch and it would only take 19/33 instances out .. so not the end of the world.
> > >>> 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. >
Now, on which kernel does this compile/work ? Do you have a "helper" program you can share that starts/exec's an app under a new container (uhmm, namespace). No point for us to actually write that..
-- Hubertus
- 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/
| |