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
Attachment:
signature.asc
Description: To jest =?iso-8859-2?Q?cz=EA=B6=E6?= listu podpisana cyfrowo
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
