How to deliver a kernel module that doesn't have to be rebuilt for every kernel update

Latest response

We are using the open source project riffa to generate a kernel module to communicate with a PCIe card

At the moment we build effectively a kmod rpm, i.e. the .ko file we deliver was built against and is specific to only one exact kernel version

This means that for every kernel update we need to rebuild our riffa.ko against the new kernel and generate a new rpm to deliver it

I have seen mention of akmod and dkms being ways of getting the kernel module to be rebuilt on the fly when a kernel update occurs but neither of these packages are in the core RHEL 6 rpms (although they are available from EPEL)

As those tools are not part of the standard rhel6 distribution is there some other way we should be doing this ?

Alec Keeler

AK
Log in to join the conversation

Responses

Akemi Yagi's picture Guru 2404 points
19 September 2017 5:08 PM

You may want to look into ELRepo's kmod packages (see FAQ ). By design, they survive kernel updates transparently without the need for development packages.

Jamie Bainbridge's picture Red Hat Guru 7257 points
19 September 2017 10:47 PM

If you use only symbols which are on the KABI whitelist, these are guaranteed to be stable over the life of a major release:

If you use non-stable symbols, these are not guaranteed to be stable, so you need to be aware of when the interface (either API or ABI) changes and change code and/or recompile as required. As Akemi said, the ELRepo method can be helpful here. Akmods and DKMS are in EPEL.

If you have a business case for making an unstable symbol stable, you may request this via a support case. We have definitely taken requests from development partners to stabilise symbols in the past. However, be aware that we can't make every symbol stable as we need scope to change at least some things over the life of a RHEL release, so we may deny stability requests for some symbols.

AK Newbie 15 points
20 September 2017 9:41 AM

Thanks for the response, looks like what I need to do is deliver my .ko module to a /lib/modules/"build_kernel_version"/extra directory then call /sbin/weak-update in the rpm postinstall to get it linked up to the current kernel.

Then when a kernel update occurs in future, the kernel rpms postinstall calls /sbin/weak-update to link them up to the new kernel automatically as long as they are compatible

As far as whether the symbols are in the KABI whitelist I'm not sure as its not our driver (its from http://riffa.ucsd.edu/) but rather than trying to get my head around someone else's kernel module source I'm going to give it a try and see if it works, my issue is more with the packaging it into an rpm properly that plays friendly with kernel updates

AK Newbie 15 points
20 September 2017 10:20 AM

Also for those making rpms in the std manner (we have a custom in house process) the package redhat-rpm-config delivers a kmodtool that assists in the generation of kmod rpms, it generates the required code for the rpm scripts. I'm a bit surprised that there's no man page for /sbin/weak-update

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.