lkml.org 
[lkml]   [2006]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: (pspace,pid) vs true pid virtualization
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.
-
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/

\
 
 \ /
  Last update: 2006-02-16 22:14    [W:0.918 / U:0.416 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site