kernel versioning

[Leszek Matok]

Dnia 10-03-2006, pią o godzinie 09:44 +0100, Axel Thimm napisał(a):
> But tons of kernel module projects check on the version of the kernel
> and trigger different code bits. These projects depend on the
> versioning to decide whether some features exist or not.
2.6.17-pre1 will have SUBLEVEL=17 and EXTRAVERSION=-pre1. It will have
LINUX_VERSION_CODE equal to KERNEL_VERION( 2, 6, 17 ). It won't have
most of the changes to come in "real" 2.6.17. Does every module maker
check for EXTRAVERSION in /lib/modules/`uname -r`/build/Makefile,
extracts "pre" or "rc" part in case there are some other suffixes (like
-git7-mm3-ac4) and knows that rc1 > pre100? My guess is no.

There are more problems if you consider the fact that any (vendor/user)
patched kernel may have an API change that won't make it into the next
(or any) official Linux version or it may have some official-kernel
change removed.

API/ABI/whatever changes should be marked using some specific #defines
which can be checked instead of depending on a non meaningful version
number. There are CONFIG_ defines that can break modules, but they can
be detected and made to work (for example, NVIDIA proprietary driver
recently learned to work with CONFIG_4KSTACKS). If some change
_requires_ testing for kernel version (which doesn't mean that much,
really), it's just wrong. It forces the module maker to trace every
change in the kernel and make code fragments compiled conditional under
different kernel version _ranges_ (and he has to continually check if
current range isn't about to end) instead of just depending on something
defined globally, upstream and changed when API changes occur.

Besides... who cares? USER shouldn't have to worry about compiling
kernel modules, he/she expects to get it with their system. Programmers
and rpm builders can deal with problem themselves so that I get working
module (in our case, from FC or FE). If a patch is required, it becomes
unnecessary upon next Fedora major kernel upgrade (if you're right).
Proprietary module vendors have their own programming forces that can
and should fix things if they're paid for it. Fedora is "big" enough
distro to afford changing the kernel (with good intentions :)) and
expecting others comply if they're not kind enough to give out sources.

Lam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: To jest =?iso-8859-2?Q?cz=EA=B6=E6?= listu podpisana
	cyfrowo
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20060310/9254db49/attachment-0002.bin