[fab] kernel modules

[Josh Boyer]

On Wed, 2006-09-20 at 09:49 -0400, Jesse Keating wrote:
> 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 

Yes, there is.  DaveJ said no, and I don't blame him.  If it lives IN
the kernel src.rpm, then bugs get filed against that and the problem
lies back on the Core kernel developers.

> 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.

Considering the number of people that work on it now, and the things
needed to keep in sync, I find that to be just as complex as keeping
them in their own package.  For example, you do _not_ want to hold up a
Core kernel security fix because someone from the community has a driver
that needs updating.  It's the same damn argument, only now it prevents
the security fix from getting out for _everybody_ not just the ones
using said module.

josh