Messages in this thread | | | Date | Thu, 02 Feb 2006 14:50:41 +0100 | From | Greg <> | Subject | Re: RFC [patch 13/34] PID Virtualization Define new task_pid api |
| |
Eric W. Biederman wrote: > Greg <gkurz@fr.ibm.com> writes: > > >>Eric W. Biederman wrote: >> >>>On this front I have been planning on using sys_clone as it allows >>>pieces of the virtualization to be incrementally built, it already >>>supports the FS namespace, and it supports flexibly specifying what >>>you want to contain. >>> >> >>What would you do to handle the following case: >> >>pid = getpid(); >>if (sys_clone(CLONE_CONTAINER) == 0) { >> ppid = getppid(); >> assert(ppid == pid); >>} >> >>Most of the calls involving resource ids will return values that aren't >>*consistent* with ids already stored in userland... could possibly break some >>piece of code. Perhaps a sys_exec() should also be enforced to reset the process >>memory. > > > Well that assertion will fail. > At that point getppid() will return 0, and getpid() will return 1. > > Processes getting confused is their own problem. >
This flavour of clone should be used with great care then since it breaks the usual unix process semantics. :)
> Now there will be a pid that the parent sees that will not be 0. > And that is what the parent will see in the context of wait. > > In my code I introduced a wid (wait id) for that purpose. >
Is it possible to see the code ?
> This makes it possible to manage a container using the usual unix > process semantics. Which is very important. > > > Eric >
Thanks.
-Greg- - 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/
| |