From: Rik van Riel (riel_at_surriel.com)
Date: Mon 22 Sep 2003 - 19:53:23 BST
Hi,
I'm wondering how much of the 2.4 vserver infrastructure
is really needed to achieve the same functionality in 2.6.
I suspect that we need to look at reimplementing some of
the vserver functionality with other components of the
kernel, so the vserver patch becomes smaller and could
even be merged into the main line kernel.
Ideally vserver would be standard functionality and not
a separate fork.
For the various components of vserver, I could envision
using these technologies:
- unbreakable chroot
--> filesystem namespaces, CLONE_NS, recursive bind mount
(already in 2.4 and 2.6 kernels, needs userspace helper)
- separated out /proc namespaces
--> cannot be done yet, needs vserver implementation
reuse same implementation for selinux ?
- firewalling, probably IP address binding
--> netfilter & selinux framework
- cpu & memory resource use of vservers
--> CKRM, see http://ckrm.sourceforge.net/
- network resource use of vservers
--> reuse normal traffic control infrastructure,
maybe selinux infrastructure
- per-vserver disk quota
--> maybe the selinux people are interested in this too ?
make this something generic, beyond just vserver
This leaves one, maybe two, components of vserver that need a
special vserver specific implementation. The rest can be done
using already existing or generic-but-still-in-development
infrastructure.
Having vserver as small as possible should not only make it
easier to maintain, but also to get it merged upstream.
What do you think?
Rik
-- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan