Dear VServer Community! first, thanks for the positive feedback! one can dream, but many can accomplish ...
As promised, here is a description what I had in mind for the (nightly) automated vserver kernel build/test ... a short version of possible benefits: - all-in-one patches for all possible scenarios ... - regression tests and error reports - automated rediffing (dream on ;) - automated testing (it does/not boot ;) - performance values how to do ... setup a space, large enough to hold (linked) copies of 2-3 kernel versions (2.4.20, 2.4.21, 2.4.22) and the recent pre/rc versions (pre1- pre5) in variations of all 'useful' vserver kernel enhancements/patches (mq, cx, cq, ml, dl, vr, rmap, xy, yz) so that those are available for build/testing and compile them with different setups/configs probably for the most common architectures, to produce a large set of patches, together with an error log documenting the build process ... In the second stage those kernels could be fed into an automated testing (with QEMU for example) to verify basic functionality, again producing reports on any failure ... this would allow to concentrate on real kernel development instead of rediffing patches over and over again ... Now for the machine/disk requirements: I tried this once on a 40GB space and it wasn't nearly enough ... A 2.4 kernel in dormant state uses ~180MB disk space, a 2.6 kernel ~220MB .. on build this is around 300-400MB depending on the configuration, if you keep 5 kernels in built state for 5-6 patches each, you are at 15GB just for one architecture, and of course we want to do cross compile tests too ;) you can reduce the actual usage by building only those kernels you want to test, but this adds great overhead as kernel builds are slow and requires some good scripting (which means, it has to be done by someone ;) everything speeding up the build/test process would be advantageous, so huge amounts of RAM (for buffering) and powerful CPU's are welcome, but some kind of distributed system would be a good solution too, again it just needs someone to look after it ... of course all this can be done inside one or more vservers, without any issues, but I guess the testing would require loop and network access to setup QEMU harddisk space, etc ... best, Herbert
