PID virtualization: a wealth of choices [LWN.net]

PID virtualization: a wealth of choices

Posted Feb 11, 2006 12:39 UTC (Sat) by ebiederm (subscriber, #35028)
Parent article: PID virtualization: a wealth of choices

My approach does address the architecture for the larger issue.

I just assume that we won't solve all of the problems simultaneously. The problem is just to big. So by taking the problem one namespace at a time we can incrementally get code into the kernel. As well as allowing flexibility as well.

I am reusing the architecture we already have that has used tasks to build threads, and processes. I am just taking the next step to build virtual
private servers/guest/containers/... Whatever you want to call them.

Eric

(Log in to post comments)

PID virtualization: a wealth of choices

Posted Feb 18, 2006 9:35 UTC (Sat) by dev (guest, #34359) [Link]

Eric, you know well that your approach has disadvantages:
- you introduce strong isolation, when host can't access container.
This makes containers less manageable. For example, in OpenVZ host system can control processes from VPS. You can gdb/strace/kill etc. You can use ps/top and all the existing tools. In your case, you need to introduce new syscalls, which would allow to ptrace/kill foreign processes and you need to patch all the management tools in the world.
- On the other hand VPID approach can be easialy used for both weak/strong isolation. It doesn't care.
- you mess up with interfaces like clone().
- I wouldn't mention your approach to procfs, while OpenVZ virtualizes this FS.
- you missed a lot of issues/bugs/SMP races which were pointed to you

Just my 2 cents if you start making PR.