Messages in this thread | | | Date | Fri, 17 Feb 2006 10:11:09 +1300 | From | Sam Vilain <> | Subject | Re: (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/
| |