How to package kernel module

Dave Jones davej at redhat.com
Thu Sep 1 21:22:40 UTC 2005


On Thu, Sep 01, 2005 at 05:17:23PM -0400, Jeff Spaleta wrote:
 > On 9/1/05, Dave Jones <davej at redhat.com> wrote:
 > > 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.
 > 
 > Assuming kernel modules will at some point exist in Extras.....is
 > there a way to have Extras modules 'taint' the log messages so that
 > its easier to spot this sort of situation so the general triagers can
 > ask reporters to reproduce the problem with the addon modules removed?

The fact that they won't be signed with the same gpg key that we sign
modules with at build time means they'll show up in lsmod as 'U'
(unsigned), so they tend to stick out like a sore thumb.
This has actually been really useful for diagnosing some RHEL4 bugs, where
people do things like rebuilding a different jbd.ko to the one we ship.

 > This is a very tough nut.   I really don't have any policy or even any
 > wacky un-implementable tool implementations that are going to pretend
 > to address this. As long as upstream kernel is driving forward
 > agressively without an established API for external module writers
 > there really isn't much to be done here. Extras modules are simply
 > going to break with kernel updates on occasion and downstream
 > packagers are going to have to bust their hump fixing the addon
 > modules.

As Spot pointed out though, the one real answer is 'pressure maintainers
into getting their code upstream'.  For some modules it'll just be
a lot more work than for others, but ultimately, everyone benefits
from the results.

		Dave




More information about the fedora-extras-list mailing list