[fab] kernel modules

[Christopher Blizzard]

Jesse Keating wrote:
> 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:

I'll draw a correlary for a moment and say that this happens in a lot of 
places in the OS.  If we update a package that has dependencies, and 
some of the deps have to move, we have that problem today, no?  Yes, the 
kernel is a special case because it's more of a moving target and the 
lack of internal APIs makes this harder, but it's something that we're 
at least a little used to, even if it's to a lesser degree.

It might be enough to say "hey, if the kernel moves, it moves" and kmod 
packagers have to follow.

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

:P  An opportunity to make some changes to RPM that enables this kind of 
behavior?

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

Right now there's no chance for them to work together.  Set up a kmod 
mailing list and get everyone on the same page?  i.e. if you want to 
maintain a kmod, get on the list and learn from others.  I see this is a 
chance to teach and bring a community closer together.  We just need to 
have a set of signposts to get people pointed in the right direction.

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

I like the goal here - encouraging external people to participate - but 
there's stuff that lives outside of the kernel today.  The natural 
reflection for that is separate packages, not addons into the kernel 
package.

Yes, kmod has downsides.  But on balance, doesn't the idea of enabling 
external folks to add kernel modules and participate on an important 
piece of our story worth the cost?

We'll learn as we go, and maybe we'll decide that it totally sucks. 
(Failure needs to be OK, IMHO.  If we're not failing we're not trying.) 
  Or maybe we'll learn that we need to change the way the package system 
works for the kernel.  But right now we can't even figure that out 
because we're not even willing to try.

--Chris