How to package kernel module

Dave Jones davej at
Thu Sep 1 20:58:21 UTC 2005

On Thu, Sep 01, 2005 at 03:45:20PM -0500, Tom 'spot' Callaway wrote:
 > On Fri, 2005-09-02 at 00:33 +0400, Paul P Komkoff Jr wrote:
 > > Is there any consensus on kernel module packaging?
 > > 
 > > I am willing to submit a whole bunch of telephony-related stuff. Whole
 > > bunch includes zaptel. Zaptel includes a small pile of kernel modules.
 > > 
 > > Should I use livna template (kernel-module-zaptel) or base template
 > > (zaptel-kernel) ? How I need to decorate my specfile to have module
 > > subpackages built for smp AND up kernel?
 > Right now, FE is not setup for kernel-module-* packages. We still have
 > several lightyears to go before we can get there.
 > On top of that, I'm very hesitant to include kernel-module-* packages on
 > principle. I feel strongly that most of the packages that we could
 > include (open source, not patent infringing) should be going upstream so
 > that they can get in the FC kernels.
 > So, my first question is: Why aren't the zaptel kernel modules in the
 > upstream 2.6 tree?

It's a tough call. A lot of out-of-tree modules are in a really bad shape
and nowhere near standards for submission upstream.  A few days ago
I looked at the ralink driver for example. It needs so much effort to
make it a) look like a linux driver b) use in-kernel functionality
instead of reinventing everything that it's probably easier to rewrite
the driver from scratch when the 80211 code settles down than it would
be to clean it up.

This might sound like a positive reason _for_ including it in extras,
but the situation is a lot of these drivers are of so poor quality
that I really have no faith in them at all.  If I get kernel bug
reports filed with modules I don't recognise, the first thing I'm
going to ask is to try and repeat it without those modules, regardless
of whether they're GPL, have full source etc.

There's also another problem.  When people start depending on out-of-tree
kernel modules, they become reluctant to upgrade their kernel.
For eg, I'm still getting new bugs filed against the 2.6.10 kernel
because people are tied to a particular driver (not just binary ones either,
opensource ones that just don't compile against newer trees).
Despite the fact there have been numerous updates since then, all the way
up to 2.6.12.  If people hold onto old kernels due to out of tree modules
lagging behind, I'm going to be left with little alternative than
to close bugs filed against older releases as CANTFIX, and have them
reopen them if/when they ever upgrade.

[Note: I've not actually reviewed the Zaptel drivers, the comments
above are a general statement].


More information about the fedora-extras-list mailing list