mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: Kirill Korotaev <dev@sw.ru>,
	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>
Subject: Re: (pspace,pid) vs true pid virtualization
Date: Wed, 15 Feb 2006 15:12:13 -0700	[thread overview]
Message-ID: <m11wy4s24i.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20060215145942.GA9274@sergelap.austin.ibm.com> (Serge E. Hallyn's message of "Wed, 15 Feb 2006 08:59:42 -0600")

"Serge E. Hallyn" <serue@us.ibm.com> writes:

> Hi,
>
> the lkml discussion on pid virtualization has been covering many of the
> issues both relating directly to pid virtualization, and relating to
> optimizations in the two specific implementations.
>
> 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.

Does anyone see problems with implementing this as series of namespaces?
If not we can move forward and start talking about pids, and the
other namespaces.

With respect to pids lets not get caught up in the implementation
details.  Let's first get clear on what the semantics should be.

- Should the first pid in a pid space have pid 1?

- Should pid == 1 ignore signals, it doesn't have a handler for?

- Should any children of pid 1 be allowed to live when pid == 1 is killed?

- Should a process have some sort of global (on the machine identifier)?

- Should the pids in a pid space be visible from the outside?

- Should the parent of pid 1 be able to wait for it for it's 
  children?

- Is a completely disjoin pid space acceptable to anyone?

- What should the parent of pid == 1 see?

- Should a process not in the default pid space be able to create 
  another pid space?

- Should we be able to monitor a pid space from the outside?

- Should we be able to have processes enter a pid space?

- Do we need to be able to be able to ptrace/kill individual processes
  in a pid space, from the outside, and why?

- After migration what identifiers should the tasks have?

If we can answer these kinds of questions we can likely focus in
on what the implementation should look like.  So far I have not
seen a question that could not be implemented with a (pspace, pid)/pid
or a vpid/pid implementation.

I think it is safe to say that from the inside things should look to
processes just as they do now.  Which answers a lot of those
questions.  But it still leaves a lot open.

Eric

  reply	other threads:[~2006-02-15 22:20 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-15 14:59 Serge E. Hallyn
2006-02-15 22:12 ` Eric W. Biederman [this message]
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
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=m11wy4s24i.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --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=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

all inboxes | Powered by JetHome®