On Tue, Feb 06, 2007 at 10:57:02AM -0800, Thomas Chung wrote: > Good news. > Fabrice Bellard, the creator of qemu is now releasing kqemu under GPLv2. > Previously it was released with propriety license. > http://fabrice.bellard.free.fr/qemu/kqemu-changelog.html > Cheers! I have packaged it at ATrpms: http://atrpms.net/name/kqemu/ Other than being useful per se, take it as a demonstration of what the technology around external packaging can offer. No need to wait for upstream vanilla and/or kernel rpm to add it, people needing it including developers at Fedora/RH in matters of virtualization can make use of it immediately. kernel modules packaged outside the kernel have been splitting the developer community of Fedora for some time now, and even the supporters are split in three camps, two binary rpms providing solutions (kmdls and kmods) and one on-the-fly-user-build solution (dkms). I don't want to go too much into political details, e.g. whether Fedora needs to pressure authors to submit to the kernel or not, and if they do submit, how often they should etc. I'm more interested in the technical issues ATM. Just as a fact sheet disarming some of the arguments against kmdls: o scales well: One person can support 11 kernels (it was 17 until 01.01.2007 when ATrpms dropped RHL7.3-FC4 support) for several kmdls for several years now in his spare time. o negligible buildsystem size: In ATrpms' buildsystem support for kmdls took about 100-150 lines of sh, it will not be more for any other buildsystem o very small lead-time: new kmdls for new kernels are in the repo usually less than an hour after a kernel update is made known to me - if the support were in the same build environment this could boil down to minutes and become part of a kernel package release. o "rolling kernel upgrade": No, kmdls cannot do that, but can achieve a similar goal: no reboots for updating non-core parts of the kernel. If parts of the kernel like wireless drivers are officially maintained as kmdls instead of being part of the kernel we wouldn't need to ask for kernel updates whenever a driver needs updating. If the kernel itself doesn't need that often to be swapped this means less reboots and larger uptimes. An existing example are the 1.2.0 and 1.2.1 ipw2200 drivers at ATrpms. Users can switch to and from them w/o a reboot. Another is the fuse kernel module bug (bug #221420) fixed on-the-fly with a kmdl. Of course the main problems remain, but are more social/political ones: o kernel package developers lose control over what the user has installed kernel-wise, it can make debugging more difficult if the user chooses not to mention that he's not using the plain kernel rpm. But better to have th user install foo-kmdl, then foce him to make install in foo and have a non-unistallable, non-packaged foo mangled in the kernel. o kernel module authors may become lazy and not submit (as often) to the kernel. But sometimes this is even not wanted: For example the lm_sensors project can submit to 2.6, but not 2.4 anymore, so they ship kmdls only for 2.4. RHEL3 is feature-frozen, no kqemu will make it in the kernel there, but kmdls for it are available in the URL above. So in fact I think that some of the (political) arguments against kmdls even have a part in favour. -- Axel.Thimm at ATrpms.net
Attachment:
pgpyoOAM1uZNB.pgp
Description: PGP signature
_______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board
_______________________________________________ fedora-advisory-board-readonly mailing list fedora-advisory-board-readonly@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board-readonly
