external kernel modules (was: kqemu is now GPLv2)

[Axel Thimm]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/advisory-board/attachments/20070209/9ddf659c/attachment.bin