[fab] kernel modules

Jesse Keating jkeating at redhat.com
Wed Sep 20 13:49:08 UTC 2006


On Tuesday 19 September 2006 16:04, Toshio Kuratomi wrote:
> Arguments against kmods:
> * It makes the job of diagnosing kernel bugs harder as there could be
> extra kmods on top of a stock fedora kernel.
> * kmods and kernels could go out of sync.

Wrong.  By nature, kmods and kernels will ALWAYS get out of sync.  This will 
prevent security updates from installing on a users system until the kmod 
developer gets around to rebuilding the module.  This is a REALLY poor user 
experience.  Further arguments against kmods include:
 * no sane way to package them, everything is just a hack
 * no sane way to manage installation/upgrades.  RPM just does not mesh well 
with the way that kmods need to operate.  The way rpm handles kernel is a bit 
hacky, multiple releases of a package installed at the same time.  Throwing 
addon packages to this in the mix makes the whole RPM system spiral downhill 
in a hurry.
 * kmod developers are largely out of the loop in kernel developments and 
directions of the kernels.  This is somewhat solveable but hard to keep up 
especially if we allow more and more kmods in where the packare is just that 
a packager, and not a kernel developer.

>
> Arguments for kmods:
> * It makes the job of the end-user easier because they need the
> functionality anyway and will get it from another source if necessary.
> * It makes the job of the kernel developers easier because they at least
> know the end-user is using a kmod from fedora-extras (and can ask: "if
> you rpm -qa |grep kmod does that turn up anything?"  whereas a from
> source kmod would not leave that evidence.)

Um, lsmod is pretty easy to run.  And its quicker than rpm -qa.  This argument 
is bunk.

> * Fedora is a home for all open source software.  Open source kmods are
> part of that definition.

Yes, however there is no reason why these kmods couldn't live IN the kernel 
src.rpm and not in separate packages.  I'm not against Fedora including 
kernel modules that aren't in the upstream tree.  I'm against including them 
in standalone packages.  These modules will not be available at install time 
if in separate packages.  If we care enough about the module and enough to 
make it available at install time and as official packages/updates, we should 
invest the time to get it into the kernel source package so that it is always 
released at the same time and gets the same attention.  The real challenge is 
making it easier for the community to assist in the kernel development, not 
in creating subpackages of modules that only makes it more complex and 
difficult.

[snip]

-- 
Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-advisory-board/attachments/20060920/dc394810/attachment.sig>


More information about the fedora-advisory-board mailing list