Hi Pavel, On Mon, Nov 24, 2008 at 7:46 AM, Pavel Emelyanov <xemul@xxxxxxxxxx> wrote: > Michael Kerrisk wrote: >> Pavel, Kir, >> >> Drawing fairly heavily on your LWN.net article (http://lwn.net/Articles/259217/), plus the kernel >> source and some experimentation, I created the patch below to document CLONE_NEWPID for the clone(2) >> manual page. Could you please review and let me know of any improvements or inaccuracies. > > Michael, sorry for the late response - I've been on vacation last week and didn't > have chance to connect to check my mail. No problem. > Some comments are inline. Thanks! [...] >> +This flag is intended for the implementation of control groups. > > Well, actually this has nothing to do with control groups. This > flag is intended to be used to facilitate the creation of containers > along with many other clone flags. Control groups is yet another > way to create a container. Yep, after an earlier mail from Eric, I already changed this to "containers". >> +A PID namespace provides an isolated environment for PIDs: >> +PIDs in a new namespace start at 1, >> +somewhat like a standalone system, and calls to >> +.BR fork (2), >> +.BR vfork (2), >> +or >> +.BR clone (2) >> +will produce processes whose PIDs within the namespace >> +are only guaranteed to be unique within that namespace. > > Well, I'm not sure I understood correctly what was meant here, but after I've simplified that sentence somewhat. Now it just reads: A PID namespace provides an isolated environment for PIDs: PIDs in a new namespace start at 1, somewhat like a standalone system, and calls to fork(2), vfork(2), or clone(2) will produce processes with PIDs that are unique within the namespace. > we have a namespace each task has two pids. And _all_ of them are unique > in corresponding namespaces. And I already make that point lower down in the text (see ***), but now I extended the sentence there a little. [...] *** Here's where I make the point about each process having multiple PIDs" >> +The existence of a namespace hierarchy means that each process >> +may now have multiple PIDs: >> +one for each namespace in which it is visible. I added some words here: "each of these PIDs is unique within the corresponding namespace". >> +(A call to >> +.BR getpid (2) >> +always returns the PID associated with the namespace in which >> +the process was created.) > > I don't thinks it's a good example - the getpid cannot be called > for other process other than current :) It wasn't meant as an example. The point was, with a process potentially being a member of multiple namespaces, the reader might wonder: what does getpid(2) return? This sentence was intended to clarify that. With that explanation, does this sentence now seem okay? [...] Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
