[elrepo-devel] Two things about kversion

[Phil Perry]

Farkas Levente wrote:
> On 04/20/2010 03:29 AM, Akemi Yagi wrote:
>> Hi all,
>>
>> I would like to start a discussion about a couple of things regarding
>> "kversion".
>>
>> (1) Which version of kernel should a kmod package be built against?
>>
>> Many kmod packages provided by ELRepo are compatible through all
>> versions of kernel within CentOS 5.x thanks to the kABI. However,
>> there are those that are valid only with certain version and up.  So,
>> the question arises: should we always build a kmod package against the
>> oldest possible kernel -- or the newest possible --or -- ?
>>
>> (2) Is it a good idea to hardcode the kversion in the spec file?
>>
>> This question is related to the first one. It is not instantly obvious
>> which kernel was used as a base for a given kmod.  Hardoding the
>> kversion in the spec file would make it easy to identify it.  Another
>> reason (and this may be more important) is that mock can be used for
>> building if kversion is defined in the spec.
>>
>> Please let me know your thoughts.
> 
> i vote for the oldest possible version which is good enough to build it 
> and hardcode it into the spec file. otherwise it very difficult to build 
> in mock since in mock uname -r is NOT the chrooted env's kernel but the 
> host machine's release and it cause eg. for me a lots of headache 
> (building fedora kmod on a centos build farm is rather tricky thing).
> 

Taking the second question first, I don't see any downside to defining
kversion in the SPEC compared to building against the current kernel,
which we always override on the command line anyway.

At the moment we have:

# If kversion isn't defined on the rpmbuild line, build for the current
kernel.
%{!?kversion: %define kversion %(uname -r)}

I would prefer to leave it in the current format where it can still be 
passed as a parameter from the command line, but allow the package 
maintainer to code it to the kernel that they wish the package to be 
built against by default. For example:

# If kversion isn't defined on the rpmbuild line, define it here.
%{!?kversion: %define kversion 2.6.18-8.el5}

I've just tested that and it builds fine in mock, pulling in the correct 
kernel${dashvariant}-devel build deps, and the package is indeed built 
against the correct kernel version/variant. The only thing one might 
need to consider is a patched version of redhat-rpm-config in the 
buildroot tree for building modules that require ksyms not defined in 
the current ABI.


We have discussed in the past which kernel (by default) packages should
be built against. There are logical arguments for the first 5.0 release
kernel (2.6.18-8.el5) and for the latest kernel. And then there are some
packages that are best built against a kernel somewhere in between for
kABI compatibility or build reasons. Personally, I'm in favour of
building against the latest kernel where possible rather than the first
kernel mainly because that benefits from the latest fixes. For example,
the package Akemi tried to build which failed to build on x86 because
the asm stuff was missing (was it powernow-k8 ??). Anyway, it got fixed
in a later kernel.

Also, if a module is not kABI compliant across all kernels, then
presumably we intend to primarily support the latest kernel rather than
older vulnerable kernels.

But where a module is kABI compliant across all kernels, I'm not sure it
really matters which kernel it is built against - just my instinct says
it's always best to use the latest where possible. Ultimately, I think 
it largely depends on the package.

An example of some weirdness was with the latest kmod-alsa. It will only 
build against kernels -164 and -194 (5.4 and 5.5, respectively) - builds 
against earlier kernels fail. When built against 5.4 it will weak-link 
back to 5.3 and forwards to 5.5, but when built against 5.5 it does not 
weak-link backwards at all. So clearly here building that package 
against 5.4 is the logical choice atm for the widest kABI compatibility.


Phil