[Devel] Re: semantics for namespace naming

[Serge E. Hallyn]

Quoting Dave Hansen (haveblue at us.ibm.com):
> On Thu, 2006-12-14 at 09:36 -0600, Serge E. Hallyn wrote:
> > one container corresponds to one nsproxy which is one set of namespaces.
> 
> On container has at least one nsproxy associated with it.  Did you mean
> to say here that each container has one and only one nsproxy?

Sorry, that was struct container, not container.

Since the containers are hierarchical, you can say that a "container"
"has" all the nsproxies of all it's child containers.

So when there is a container for /vserver1, and from that vserver:

	1. serge logs in and unshares the mount namespace for his
	private /tmp and /home
	2. dave starts a checkpointable job in a private container

The struct container for /vserver1 has just one nsproxy, but it has a
child container for serge's login, and a child container for dave's
checkpointable job, so you can say the vserver1 container has three
nsproxies.

> > As I said, once a process is in a container, it never leaves that
> > container.  It only enters additional ones.  That model fits everyone's
> > needs, without needing some funky API.
> 
> This makes logical sense to me.  In practice this has the feel of
> ptracing where the ptracer becomes a temporary parent of the tracee.
> 
> The process entering a container temporarily becomes a member of that
> container, but it doesn't completely _stop_ being a member of its
> container.  The real_parent of a process being ptraced may not be doing
> all of the parental duties during a ptrace, but it doesn't _stop_ being
> the real_parent.
> 
> Maybe I'm stretching the analogy too far :)

Maybe, or maybe you're showing me a kink in my reasoning.  I was in
fact thinking that entering a new container would be the one way
to fully disengage from the old container.  Meaning it would be best
if it were forced to be done on a clone+exec.  But even so, is that
reasonable?

-serge
_______________________________________________
Containers mailing list
Containers at lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers