How to package kernel module

[Paul Wouters]

On Thu, 1 Sep 2005, Dave Jones wrote:

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

Blame the kernel developers for that. In our case, we have been bitten
by a lot of the recent 2.6 kernels, because of changes to the API, or
deprecation without any kind of compatibility check in the kernel.

Fedora is making matters worse by deprecating functionality as a patch
in a previous kernel as compared to the linus kernel. This horribly
complicates things for out of tree module developers. We can no longer
do something like :

#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,13)

because in a Fedora kernel this patch is already applied to 2.6.12 or 2.6.11.

Instead, we now have to add a variable that we set for 2.6.13 kernels AND have
to hack into the spec file for Fedora based kernels to decide at build time
whether or not this Fedora kernel version has that particular code in earlier
kernel versions too.

This has now happened to us I believe in 2.6.8, 2.6.11 and  2.6.12 /  2.6.13.
eg we needed to create HAVE_SOCK_ZAPPED, NET_26_12_SKALLOC and HAVE_SOCK_SECURITY.
It is not really making rpm building easier.

And finally, whoever changed the argument order for sk_alloc deserves to be on
a life support machine running said kernel.

Paul, back to debugging his kernel module for 2.6.12.....