mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Al Viro <viro@ftp.linux.org.uk>
Cc: "Serge E. Hallyn" <serue@us.ibm.com>, Andi Kleen <ak@suse.de>,
	linux-kernel@vger.kernel.org, herbert@13thfloor.at, dev@sw.ru,
	sam@vilain.net, xemul@sw.ru, haveblue@us.ibm.com, clg@fr.ibm.com,
	frankeh@us.ibm.com
Subject: Re: [PATCH 1/9] nsproxy: Introduce nsproxy
Date: Wed, 10 May 2006 12:45:09 -0600	[thread overview]
Message-ID: <m1ejz1wwga.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20060510100057.GA27946@ftp.linux.org.uk> (Al Viro's message of "Wed, 10 May 2006 11:00:57 +0100")

Al Viro <viro@ftp.linux.org.uk> writes:

> On Tue, May 09, 2006 at 09:11:29PM -0500, Serge E. Hallyn wrote:
>> Introduce the nsproxy struct.  Doesn't do anything yet, but has it's
>> own lifecycle pretty much mirrorring the fs namespace.
>> 
>> Subsequent patches will move the namespace struct into the nsproxy.
>> Then as more namespaces are introduced, such as utsname, they can
>> be added to the nsproxy as well.
>
> Is there any reason why those can't be simply part of namespace?  I.e.
> be carried by the stuff mounted in standard places...

Wee...  Exploring the implementation space.

So the namespaces under discussion are:
- The uts namespace
- The sysvipc namespace
- The pid namespace
- The network namespace
- The uid namespace
- The time namespace

None of which are currently expressed as a standard mount,
so there is not an obvious mapping.  Suggestions?

A standard mount location is not strong enough,
it must be a fixed mount location so the kernel can
use it.

Looking at a fixed mount location in the kernel looks
likely to be too clumsy to use we would need pointers
similar to those in fs_struct to cache the mount,
and we would still have the problem of identifying which
mounts from kernel space are for the different namespaces.

I am a little concerned about the overhead in implementing
this on the kernel side but those are simply implementation
optimization issues not semantic issues.

Exporting the different kernel namespaces/subsystem through
filesystems sounds reasonable if it will simplify the semantics.
Currently the only practical difference I can see is that you could
use mount/umount instead of clone and unshare.  Which seems to
give us additional complications for no real gain. 

If we did not have to be backwards compatible and we could reduce our
number of system calls by exporting whole subsystem instances as
filesystem mounts I can see great gains here, but since we
are concerned with existing namespaces/subsystems and just
want to make it appear that we have multiple instances of
them I don't see any gains. 

Eric

      parent reply	other threads:[~2006-05-10 18:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <29vfyljM.2006059-s@us.ibm.com>
2006-05-10  2:11 ` Serge E. Hallyn
2006-05-10 10:00   ` Al Viro
2006-05-10 11:55     ` Serge E. Hallyn
2006-05-10 12:20       ` Herbert Poetzl
2006-05-10 18:45     ` Eric W. Biederman [this message]

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=m1ejz1wwga.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=ak@suse.de \
    --cc=clg@fr.ibm.com \
    --cc=dev@sw.ru \
    --cc=frankeh@us.ibm.com \
    --cc=haveblue@us.ibm.com \
    --cc=herbert@13thfloor.at \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sam@vilain.net \
    --cc=serue@us.ibm.com \
    --cc=viro@ftp.linux.org.uk \
    --cc=xemul@sw.ru \
    /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®