Re: (pspace,pid) vs true pid virtualization

[Sam Vilain <sam@vilain.net>]

Dave Hansen wrote:
> Brainstorming ... what do you think about having a special init process
> inside the child to act as a proxy of sorts?  It is controlled by the
> parent vserver/container, and would not be subject to resource limits.
> It would not necessarily need to fork in order to kill other processes
> inside the vserver (not subject to resource limits).  It could also
> continue when the rest of the guest was suspended.
> A pid killer would be ineffective against such a process because you
> can't kill init.  

Well, another approach would be to create a new context which has
visibility over the other container as well as the ability to send
signals to it.

>>In general, I prefer to think of this as working 
>>with nuclear material via an actuator from behind 
>>a 4" lead wall -- you just do not want to go in 
>>to fix things :)
> Where does that lead you?  Having a single global pid space which the
> admin can see?  Or, does a special set of system calls do it well
> enough?

I don't like this term "single global pid space".  Two containers might
be able to see all processes on the system, one might have a flat
mapping to all PIDs < 64k (or pid_max), one with the XID,PID encoded
bitwise.  They are both global pid spaces, but there is no "single" one,
unless that is all you compile in.

Sam.