public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Hubertus Franke <frankeh@watson.ibm.com>
Cc: "Serge E. Hallyn" <serue@us.ibm.com>, Sam Vilain <sam@vilain.net>,
	Rik van Riel <riel@redhat.com>, Kirill Korotaev <dev@openvz.org>,
	Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, clg@fr.ibm.com,
	haveblue@us.ibm.com, greg@kroah.com, alan@lxorguk.ukuu.org.uk,
	arjan@infradead.org, kuznet@ms2.inr.ac.ru, saw@sawoct.com,
	devel@openvz.org, Dmitry Mishin <dim@sw.ru>,
	Andi Kleen <ak@suse.de>, Herbert Poetzl <herbert@13thfloor.at>
Subject: The issues for agreeing on a virtualization/namespaces implementation.
Date: Tue, 07 Feb 2006 15:06:51 -0700	[thread overview]
Message-ID: <m17j86dds4.fsf_-_@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <43E90716.4020208@watson.ibm.com> (Hubertus Franke's message of "Tue, 07 Feb 2006 15:46:14 -0500")


I think I can boil the discussion down into some of the fundamental
questions that we are facing.

Currently everyone seems to agree that we need something like
my namespace concept that isolates multiple resources.

We need these for 
PIDS
UIDS
SYSVIPC
NETWORK
UTSNAME
FILESYSTEM
etc.

The questions seem to break down into:
1) Where do we put the references to the different namespaces?
   - Do we put the references in a struct container that we reference from struct task_struct?
   - Do we put the references directly in struct task_struct?

2) What is the syscall interface to create these namespaces?
   - Do we add clone flags?  
     (Plan 9 style)
   - Do we add a syscall (similar to setsid) per namespace?
     (Traditional unix style)?
   - Do we in addition add syscalls to manipulate containers generically?

   I don't think having a single system call to create a container and a new
   instance of each namespace is reasonable as that does not give us a
   path into the future when we create yet another namespace.

   If we have one syscall per each namespace why would we need a container
   structure?

3) How do we refer to namespaces and containers when we are not members?
   - Do we refer to them indirectly by processes or other objects that
     we can see and are members?
   - Do we assign some kind of unique id to the containers?
  

4) How do we implement each of these namespaces?
   Besides being maintainable are there other constraints?


5) How do we control the resource inside a namespace starting
   from a process that is outside of that namespace?
   - The filesystem mount namespace gave an interesting answer.
     So it is quite possible other namespaces will give
     equally interesting and surprising answers.


6) How do we do all of this efficiently without a noticeable impact on
   performance?
   - I have already heard concerns that I might be introducing cache
     line bounces and thus increasing tasklist_lock hold time.
     Which on big way systems can be a problem.

7) How do we allow a process inside a container to create containers
   for it's children?
   - In general this is trivial but there are a few ugly issues
     here.

I think these are the key questions of the conversation.


Personally so long as we get true namespaces, implemented in a
performant and maintainable way that a process from the inside can't
distinguish from what we have now I have no hard requirements.

   
Eric

  parent reply	other threads:[~2006-02-07 22:08 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-06 21:57 [PATCH 1/4] Virtualization/containers: introduction Kirill Korotaev
2006-02-06 22:12 ` [PATCH 2/4] Virtualization/containers: CONFIG_CONTAINER Kirill Korotaev
2006-02-06 22:17 ` [PATCH 3/4] Virtualization/containers: UID hash Kirill Korotaev
2006-02-06 22:22 ` [PATCH 4/4] Virtualization/containers: uts name Kirill Korotaev
2006-02-06 23:00 ` [PATCH 1/4] Virtualization/containers: introduction Dave Hansen
2006-02-07 12:24   ` Kirill Korotaev
2006-02-07  3:34 ` Eric W. Biederman
2006-02-07  3:40   ` Rik van Riel
2006-02-07  6:30     ` Sam Vilain
2006-02-07 11:51       ` Kirill Korotaev
2006-02-07 14:31         ` Eric W. Biederman
2006-02-07 15:42       ` Eric W. Biederman
2006-02-07 16:18         ` Kirill Korotaev
2006-02-07 17:20           ` Eric W. Biederman
2006-02-07 22:43         ` Sam Vilain
2006-02-07 16:57       ` Hubertus Franke
2006-02-07 20:19         ` Serge E. Hallyn
2006-02-07 20:46           ` Hubertus Franke
2006-02-07 22:00             ` Eric W. Biederman
2006-02-07 22:19               ` Hubertus Franke
2006-02-07 22:06             ` Eric W. Biederman [this message]
2006-02-07 23:35               ` The issues for agreeing on a virtualization/namespaces implementation Hubertus Franke
2006-02-08  0:43                 ` Alexey Kuznetsov
2006-02-08  2:49                   ` Eric W. Biederman
2006-02-08  3:36                     ` Serge E. Hallyn
2006-02-08  3:52                       ` Eric W. Biederman
2006-02-08  4:37                         ` Herbert Poetzl
2006-02-08  4:46                           ` Eric W. Biederman
2006-02-08 19:24                         ` Stephen Hemminger
2006-02-08  5:23                 ` Eric W. Biederman
2006-02-08 14:40                   ` Hubertus Franke
2006-02-08 15:17                     ` Serge E. Hallyn
2006-02-08 15:35                       ` Kirill Korotaev
2006-02-08 15:57                         ` Hubertus Franke
2006-02-08 19:02                           ` Herbert Poetzl
2006-02-08 16:48                         ` Eric W. Biederman
2006-02-08 17:46                     ` Eric W. Biederman
2006-02-08 18:03                     ` Serge E. Hallyn
2006-02-08 18:31                       ` Hubertus Franke
2006-02-08 20:21                       ` Dave Hansen
2006-02-08 21:22                         ` Serge E. Hallyn
2006-02-08 22:28                     ` Eric W. Biederman
2006-02-20 12:11                 ` Kirill Korotaev
2006-02-20 12:41                   ` Herbert Poetzl
2006-02-20 14:26                     ` Kirill Korotaev
2006-02-20 15:16                       ` Herbert Poetzl
2006-02-08  4:56               ` Herbert Poetzl
2006-02-08 14:38                 ` Serge E. Hallyn
2006-02-08 14:51                   ` Hubertus Franke
2006-02-09  4:45               ` Kyle Moffett
2006-02-09  5:41                 ` Eric W. Biederman
2006-02-09 22:25               ` Eric W. Biederman
2006-02-07 22:58         ` [PATCH 1/4] Virtualization/containers: introduction Sam Vilain
2006-02-07 23:18           ` Hubertus Franke
2006-02-08  5:03             ` Eric W. Biederman
2006-02-08 14:13               ` Hubertus Franke
2006-02-08 15:44                 ` Kirill Korotaev
2006-02-08 16:39                   ` Eric W. Biederman
2006-02-08  2:08           ` Kevin Fox
2006-02-08  1:16             ` Sam Vilain
2006-02-08  4:21               ` Paul Jackson
2006-02-08 15:36         ` Kirill Korotaev
2006-02-08 17:16           ` Eric W. Biederman
2006-02-08 20:43           ` Dave Hansen
2006-02-08 21:04             ` Eric W. Biederman
2006-02-07 12:14   ` Kirill Korotaev
2006-02-07 14:06     ` Eric W. Biederman
2006-02-07 14:52       ` Rik van Riel
2006-02-07 15:13         ` Eric W. Biederman
2006-02-09  0:24 ` Eric W. Biederman
2006-02-09  2:18   ` Jeff Dike
2006-02-09  3:16     ` Eric W. Biederman
2006-02-09 14:28     ` Kirill Korotaev
2006-02-09 15:40       ` Jeff Dike
2006-02-09 15:49         ` Kirill Korotaev
2006-02-09 17:50           ` Jeff Dike
2006-02-09 16:38     ` Hubertus Franke
2006-02-09 17:48       ` Jeff Dike
2006-02-09 22:09         ` Sam Vilain
2006-02-09 21:56   ` Eric W. Biederman

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=m17j86dds4.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=clg@fr.ibm.com \
    --cc=dev@openvz.org \
    --cc=devel@openvz.org \
    --cc=dim@sw.ru \
    --cc=frankeh@watson.ibm.com \
    --cc=greg@kroah.com \
    --cc=haveblue@us.ibm.com \
    --cc=herbert@13thfloor.at \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@redhat.com \
    --cc=sam@vilain.net \
    --cc=saw@sawoct.com \
    --cc=serue@us.ibm.com \
    --cc=torvalds@osdl.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