[Vserver] Re: [OPoll] BME inclusion into next stable release
On Fri, Jan 06, 2006 at 11:15:06PM +0100, Herbert Poetzl wrote: OPINION POLL please check (X) all points which apply ... (according to your opinion) [ ] I had no idea about this issue/deficiency [X] I did already know about it [X] I'm already using BME (or similar) patches [ ] I will start using BME patches now [ ] I do not need/use this 'feature' at all [X] I think this SHOULD get into the next stable Linux-VServer release because ... [X] I am using it/want to use it [ ] It's more a bugfix than a feature [X] I like the idea of ro --bind mounts [ ] I think this should NOT be included into the next stable release because ... [ ] it is not thoroughly tested [ ] it is not mature enough [ ] it adds unnecessary code [ ] it should better be fixed in the mainline Linux Kernel Cheers, Christian signature.asc Description: Digital signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] File clash between libvserver and util-vserver: libvserver.so
util-vserver should be known well enough, libvserver is a project started by Benedikt Boehm in the time when Enrico was away. It provides an interface to the vserver-patched kernel. Homepage of libvserver: http://dev.croup.de/proj/libvserver/wiki Libvserver provides a shared object, libvserver.so.1, while util-vserver provides libvserver.so.0. Those two file have different origins, don't share code and have different APIs. We first hit a problem with the libvserver Debian package (unofficial, provided by Balint Laszlo Biller), which was not installable in parallel with the util-vserver package (the official one), since they both contained a libvserver.so symlink to the actual library (also in the same directories). So on the one hand libvserver somehow invades util-vserver's namespace, since clearly util-vserver's libvserver.so was there first. OTOH util-vserver's library isn't actually used by anything else then util-vserver AFAICS, so it could probably live in /usr/lib/util-vserver. I think this would be a nice and clean solution. Another option would be to drop libvserver.so (only the symlink, not the library itself) from the util-vserver .deb. The plain .so should only be used for building software against the library anyway, and since there is no such software AFAIK, it's useless. It stays the problem that there would be 2 libs in /usr/lib with the same name, different so-versions, but with different origin and authors. I don't think this as such a nice situation in the long run, because I think ther will be more of the problems we already have. Eg. what happens if Enrico descides (for whatever strange reason, since there are no users of the library) to increase the so-version.. Yet another thing would be to rename libvserver, I but I guess Benedikt wouldn't be too glad about this. What are your opinions on this? Cheers, Christian 'Greek0' Aichinger signature.asc Description: Digital signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Bug regarding comments in /etc/vservers/*/[bc]capabilities
Hi, while digging in the util-vserver source code I found a problem with the handling of comments in several files under /etc/vserver/* (bcapabilities, ccapabilities, capabilites, flags). The code that tests if a line is a comment looks for '^#$', not '^#.*$'. The attatched patch fixes this. Cheers, Christian 'Greek0' Aichinger Index: svn/scripts/vserver.functions === --- svn/scripts/vserver.functions (revision 147) +++ svn/scripts/vserver.functions (working copy) @@ -140,7 +140,7 @@ test -e $f || return 0 while read cap; do case x$cap in - (x|x\#) ;; + (x|x\#*);; (*) OPTS_VATTRIBUTE=( [EMAIL PROTECTED] --ccap $cap );; esac done $f @@ -155,7 +155,7 @@ test -e $f || return 0 while read cap; do case x$cap in - (x|x\#) ;; + (x|x\#*);; (*) OPTS_VATTRIBUTE=( [EMAIL PROTECTED] --bcap $cap );; esac done $f @@ -176,7 +176,7 @@ while read cap; do case x$cap in - (x|x\#) ;; + (x|x\#*);; (!CAP_SYSCHROOT) CAP_OPTS=( [EMAIL PROTECTED] --cap $cap ) CAPCHROOT_OPTS=( [EMAIL PROTECTED] --nochroot ) @@ -328,7 +328,7 @@ test ! -e $vdir/flags || \ while read flag; do case x$flag in - (x|x\#) ;; + (x|x\#*);; (xnamespace);; (xfakeinit) _IS_FAKEINIT=1 signature.asc Description: Digital signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Kconfig doc patch
Hi, I've written a patch that adds some more documentation to the vserver kernel config options. I hope it makes the effect of these options a bit clearer for people. CONFIG_VSERVER_HARDCPU stuff is taken from the wiki (and was the reason I wrote this patch in the first place), and is thusly licensed under the FDL. Just in case someone cares. Patch is attatched. Cheers, Christian Aichinger --- linux/kernel/vserver/Kconfig2005-06-18 22:05:30.0 +0200 +++ linux2/kernel/vserver/Kconfig 2005-06-18 23:01:35.0 +0200 @@ -24,7 +24,9 @@ default y help This enables the legacy API used in vs1.xx, which allows - to use older tools (for migration purposes). + to use older tools. + + This is only needed when migrating from older versions. config VSERVER_NGNET boolDisable Legacy Networking Kernel API @@ -42,6 +44,10 @@ help Hide proc entries by default for xid1 + This enables hiding specific entries in procfs for guest + contexts by default. So you'll have to allow guests to access + procfs entries manually, which is potenitally more secure. + config VSERVER_HARDCPU boolEnable Hard CPU Limits depends on EXPERIMENTAL @@ -49,6 +55,14 @@ help Activate the Hard CPU Limits + Linux-VServer supports a token bucket scheduler to adjust + cpu usage of the vservers. If you don't enable this option, + the scheduler will only adjust priorities for the vservers, + with this option enabled, you can also choose to use the + hard scheduler which will put the context on hold if it has + used up its cpu tokens. For details, please take a look at + documentation specific to this feature. + config VSERVER_HARDCPU_IDLE boolLimit the IDLE task depends on VSERVER_HARDCPU @@ -121,7 +135,7 @@ help Set this to yes if you want to be able to activate debugging output at runtime. It adds a probably small - overhead (~ ??%) to all vserver related functions and + overhead to all vserver related functions and increases the kernel size by about 20k. config VSERVER_HISTORY signature.asc Description: Digital signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
