Re: RFC [patch 13/34] PID Virtualization Define new task_pid api

[Hubertus Franke <frankeh@watson.ibm.com>]

On Thu, 2006-02-02 at 22:32 +0100, Cedric Le Goater wrote:
> Eric W. Biederman wrote:
> 
> > For everything except the PID namespace I am just interested in having multiple
> > separate namespaces.  For the PID namespace to keep the traditional unix
> > model you need a parent process so it is actually nesting.
> > 
> > I am interested because, it is easy, because if it is possible than
> > the range of applications you can apply a containers to is much
> > larger.  At the far end of that spectrum is migrating a server running
> > on real hardware and bringing it up as a guest on a newer much more
> > powerful machine.  With the appearance that it had only been
> > unreachable for a few seconds.
> 
> We gave a name to such containers. We call them 'application' containers
> just to make a difference with the 'system' containers, like vserver or openvz.
> 
> 'application' containers are very useful in an HPC environment where you
> can trig checkpoint/restart through batch managers. But, this model,
> really, has some virtualization issues on the edge. The virtualisation of
> the parent process of such a container is tricky, it can be in multiple
> containers at the same time, it can die (difficult to restart ...), it
> could belong to another process groups, etc. Plenty of annoying cases to
> handle.

I guess we all experienced that (see everybodies patches).

> 
> 'system' containers, like vserver or openvz, are safer because they use a
> private PID space.

Maybe we are talking about different things, but I thought our patch-set
does provide private pid spaces ( by putting <pid,container> tuple into
the same pid ). Yes, privacy is achieved only by guarding the edges, but
the next approach that was discussed on the mailing list was to indeed 
make container's first class object, hang the pid mgmt and pid lookup
off the container and thus force the isolation.
Containers then hence move up to be children of "init".

>
> Now, would it be possible to have an 'application' container using a
> private PID space and being friendly to the usual unix process semantics ?
> We haven't found a solution yet ...

Could you spell out what specific UNIX semantics you are referring to.
That would help and we can discuss whether and how they can be
addressed.

> 
> > Entering is different from execing a process on the inside.
> > Implementation wise it is changing the context pointer on your task.
> 
> yes and you could restrict that privilege to some top level container, like
> the container 0.
> 

-- 
Hubertus Franke <frankeh@watson.ibm.com>

-
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/