All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Emelyanov <xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Cc: Kir Kolyshkin <kir-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>,
	linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	lkml <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: Documentation for CLONE_NEWPID
Date: Tue, 25 Nov 2008 18:54:51 +0300	[thread overview]
Message-ID: <492C1FCB.1080405@openvz.org> (raw)
In-Reply-To: <cfd18e0f0811250746i711205dej6b98f2fba6cecc42-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

>>> +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.

OK, thanks.

>> 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".

Correct.

>>> +(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?

Yes, but I'd change "was created" into "lives in". From my POV this
sounds more clear. I do not insist however :)

> [...]
> 
> Cheers,
> 
> Michael
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Pavel Emelyanov <xemul@openvz.org>
To: mtk.manpages@gmail.com
Cc: Kir Kolyshkin <kir@openvz.org>,
	linux-man@vger.kernel.org, lkml <linux-kernel@vger.kernel.org>
Subject: Re: Documentation for CLONE_NEWPID
Date: Tue, 25 Nov 2008 18:54:51 +0300	[thread overview]
Message-ID: <492C1FCB.1080405@openvz.org> (raw)
In-Reply-To: <cfd18e0f0811250746i711205dej6b98f2fba6cecc42@mail.gmail.com>

>>> +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.

OK, thanks.

>> 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".

Correct.

>>> +(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?

Yes, but I'd change "was created" into "lives in". From my POV this
sounds more clear. I do not insist however :)

> [...]
> 
> Cheers,
> 
> Michael
> 


  parent reply	other threads:[~2008-11-25 15:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-19  2:59 Documentation for CLONE_NEWPID Michael Kerrisk
2008-11-19  2:59 ` Michael Kerrisk
     [not found] ` <4923810B.7010201-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2008-11-23 22:20   ` Serge E. Hallyn
2008-11-23 22:20     ` Serge E. Hallyn
2008-11-25 15:09     ` Michael Kerrisk
     [not found]       ` <cfd18e0f0811250709x4e2cc5cdhafb9ccf494890442-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-11-26 17:08         ` Serge E. Hallyn
2008-11-26 17:08           ` Serge E. Hallyn
2008-11-24 12:46   ` Pavel Emelyanov
2008-11-24 12:46     ` Pavel Emelyanov
     [not found]     ` <492AA241.6050004-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2008-11-25 15:46       ` Michael Kerrisk
2008-11-25 15:46         ` Michael Kerrisk
     [not found]         ` <cfd18e0f0811250746i711205dej6b98f2fba6cecc42-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-11-25 15:54           ` Pavel Emelyanov [this message]
2008-11-25 15:54             ` Pavel Emelyanov
2008-11-25 16:27             ` Michael Kerrisk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=492C1FCB.1080405@openvz.org \
    --to=xemul-gefaqzzx7r8dnm+yrofe0a@public.gmane.org \
    --cc=kir-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.