Re: [PATCH 1/9] nsproxy: Introduce nsproxy

[Herbert Poetzl <herbert@13thfloor.at>]

On Wed, May 10, 2006 at 06:55:21AM -0500, Serge E. Hallyn wrote:
> Quoting Al Viro (viro@ftp.linux.org.uk):
> > 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...
> 
> The argument has been that it is desirable to be able to unshare these
> namespaces - uid, pid, network, sysv, utsname, fs-namespace -
> separately.  Are you talking about having these all be part of a single
> namespace unshared all at once (and stored in struct namespace)?  Or am
> I misunderstandimg you entirely?

the straight forward approach was to have N (currently nine?)
different 'spaces' all referenced by a task, and the latest
idea to optimize that (Andi made that some requirement IIRC)
was to have one structure referenced by the task struct, 
which holds the references to those 'spaces'

> Andi Kleen (I believe) thinks it should be like that, all or nothing.  I
> think Herbert Poetzl had current examples where vserver is used to
> unshare just pieces, i.e. apache unsharing network but sharing global
> pidspace.

we (Linux-VServer) basically consider the various 'spaces'
building blocks (or smallest units) to build larger 
environments which are isolated or virtualized in some
aspects, but not all of them.

think of it as: chroot(), chnamespace, chcontext, chbind, ...

existing examples (just to get the idea) are:

 - cooperating applications which are limited to a subset
   of the available network addresses

 - strictly isolated (pid and resources) services on the
   same filesystem and network

best,
Herbert

> thanks,
> -serge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/