From: Sam Vilain <sam@vilain.net>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: Kirill Korotaev <dev@sw.ru>,
"Eric W. Biederman" <ebiederm@xmission.com>,
linux-kernel@vger.kernel.org, vserver@list.linux-vserver.org,
Herbert Poetzl <herbert@13thfloor.at>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Dave Hansen <haveblue@us.ibm.com>,
Arjan van de Ven <arjan@infradead.org>,
Suleiman Souhlal <ssouhlal@FreeBSD.org>,
Hubertus Franke <frankeh@watson.ibm.com>,
Cedric Le Goater <clg@fr.ibm.com>,
Kyle Moffett <mrmacman_g4@mac.com>, Greg <gkurz@fr.ibm.com>,
Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>,
Greg KH <greg@kroah.com>, Rik van Riel <riel@redhat.com>,
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
Andrey Savochkin <saw@sawoct.com>,
Kirill Korotaev <dev@openvz.org>, Andi Kleen <ak@suse.de>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Jeff Garzik <jgarzik@pobox.com>,
Trond Myklebust <trond.myklebust@fys.uio.no>,
Jes Sorensen <jes@sgi.com>, Herbert Poetzl <herbert@13thfloor.at>
Subject: Re: (pspace,pid) vs true pid virtualization
Date: Thu, 16 Feb 2006 12:24:16 +1300 [thread overview]
Message-ID: <43F3B820.8030907@vilain.net> (raw)
In-Reply-To: <20060215145942.GA9274@sergelap.austin.ibm.com>
Serge E. Hallyn wrote:
> However, if we're going to get anywhere, the first decision which we
> need to make is whether to go with a (container,pid), (pspace,pid) or
> equivalent pair like approach, or a virtualized pid approach. Linus had
> previously said that he prefers the former. Since there has been much
> discussion since then, I thought I'd try to recap the pros and cons of
> each approach, with the hope that the head Penguins will chime in one
> more time, after which we can hopefully focus our efforts.
I am thinking that you can have both. Not in the sense of
overcomplicating, but in the sense of having your cake and eating it
too.
The only thing which is a unique, system wide identifier for the process
is the &task_struct. So we are already virtualising this pointer into a
PID for userland. The only difference is that we cache it (nay, keep
the authorative version of it) in the task_struct.
The (XID, PID) approach internally is also fine. This says that there
is a container XID, and within it, the PID refers to a particular
task_struct. A given task_struct will likely exist in more than one
place in the (XID, PID) space. Perhaps the values of PID for XID = 0
and XID = task.xid can be cached in the task_struct, but that is a
detail.
Depending on the flags on the XID, we can incorporate all the approaches
being tabled. You want virtualised pids? Well, that'll hurt a little,
but suit yourself - set a flag on your container and inside the
container you get virtualised PIDs. You want a flat view for all your
vservers? Fine, just use an XID without the virtualisation flag and
with the "all seeing eye" property set. Or you use an XID _with_ the
virtualisation flag set, and then call a tuple-endowed API to find the
information you're after.
We can enforce this by simply removing all the internal macros that deal
with single PID references only; ie, enforce the XID to be used
everywhere. This removes the distinction between virtual PIDs and
"real" pids; it's not a type difference, but an XID value difference.
There are lots and lots of details I'm glossing over, but such finer
points are best discussed by trading patches.
IOW, we can stop arguing and start implementing :-).
Sam.
next prev parent reply other threads:[~2006-02-15 23:24 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-15 14:59 (pspace,pid) vs true pid virtualization Serge E. Hallyn
2006-02-15 22:12 ` Eric W. Biederman
2006-02-16 14:29 ` Serge E. Hallyn
2006-02-16 16:37 ` Eric W. Biederman
2006-02-16 17:53 ` Serge E. Hallyn
2006-02-16 18:19 ` Eric W. Biederman
2006-02-16 18:44 ` Serge E. Hallyn
2006-02-16 18:52 ` Dave Hansen
2006-02-17 10:57 ` Eric W. Biederman
2006-02-17 11:44 ` Herbert Poetzl
2006-02-17 12:16 ` Eric W. Biederman
2006-02-17 12:44 ` Herbert Poetzl
2006-02-17 13:15 ` Eric W. Biederman
2006-02-17 13:39 ` Hubertus Franke
2006-02-17 21:40 ` Herbert Poetzl
2006-02-17 11:04 ` Eric W. Biederman
2006-02-20 10:06 ` Kirill Korotaev
2006-02-17 3:35 ` Hubertus Franke
2006-02-17 14:53 ` Serge E. Hallyn
2006-02-20 9:37 ` Kirill Korotaev
2006-02-20 12:47 ` Herbert Poetzl
2006-02-20 14:34 ` Kirill Korotaev
2006-02-20 15:27 ` Herbert Poetzl
2006-02-16 14:30 ` Herbert Poetzl
2006-02-16 15:37 ` Serge E. Hallyn
2006-02-16 17:13 ` Eric W. Biederman
2006-02-16 17:57 ` Serge E. Hallyn
2006-02-20 9:54 ` Kirill Korotaev
2006-02-20 18:19 ` Dave Hansen
2006-02-16 16:59 ` Eric W. Biederman
2006-02-16 17:41 ` Dave Hansen
2006-02-16 19:12 ` Herbert Poetzl
2006-02-16 19:38 ` Dave Hansen
2006-02-16 21:11 ` Sam Vilain
2006-02-20 10:10 ` Kirill Korotaev
2006-02-20 9:50 ` Kirill Korotaev
2006-02-20 13:00 ` Herbert Poetzl
2006-02-20 14:44 ` Kirill Korotaev
2006-02-20 15:36 ` Herbert Poetzl
2006-02-20 9:13 ` Kirill Korotaev
2006-02-20 18:07 ` Dave Hansen
2006-02-15 23:24 ` Sam Vilain [this message]
2006-02-16 5:50 ` Eric W. Biederman
2006-02-20 9:17 ` Kirill Korotaev
2006-02-20 20:01 ` Sam Vilain
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=43F3B820.8030907@vilain.net \
--to=sam@vilain.net \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arjan@infradead.org \
--cc=benh@kernel.crashing.org \
--cc=clg@fr.ibm.com \
--cc=dev@openvz.org \
--cc=dev@sw.ru \
--cc=ebiederm@xmission.com \
--cc=frankeh@watson.ibm.com \
--cc=gkurz@fr.ibm.com \
--cc=greg@kroah.com \
--cc=haveblue@us.ibm.com \
--cc=herbert@13thfloor.at \
--cc=jes@sgi.com \
--cc=jgarzik@pobox.com \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=mrmacman_g4@mac.com \
--cc=riel@redhat.com \
--cc=saw@sawoct.com \
--cc=serue@us.ibm.com \
--cc=ssouhlal@FreeBSD.org \
--cc=torvalds@osdl.org \
--cc=trond.myklebust@fys.uio.no \
--cc=vserver@list.linux-vserver.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox