Missing API for handling 3rd party kernel modules

Latest response

In our company we found very frustrating that there is no "official" API how to handle 3rd party kernel modules inside RHEL.


It is especially painful for large environments where kernel updates are needed on many servers. It is probably possible to handle 3rd party kernel stuff on 10-20 servers but for large RHEL deployments it is a lot of overhead and (sometimes) many unsuccessful trials. We would like to use pure RedHat kernels without 3rd party drivers, unfortunatelly newer hardware sometimes requires hardware vendor-provided drivers, some low-level software too.


Yes, we can use dkms (packaged from Fedora or EPEL), but it is not officially supported and thus each vendor has own specific ways how to trigger kernel updates etc.


Ksplice seems to be very promising tool but it was acquired by Oracle, so I doubt it will be actively supported by Red Hat.


Have you tried using the Driver Update Program utilizing the kernel symbol whitelist and kmod packaging? It allows for standardizing the the kernel driver packaging and allowing them to persist across kernel upgraes.




Numerous OEMs and driver vendors are using this methodology to develop, build, distribute, and maintain drivers on their websites which may or may not override inbox drivers.


BTW - ksplice is TBD.





Red Hat, Inc.

We actually do have a stable kABI in RHEL-5 and RHEL-6 that third-party module writers can use to ensure that their modules work across minor updates (e.g. 5.6 ro 5.7). Symbols in kabi_whitelist (installed by the kernel-devel package) are typically the ones to use in your module to make sure that the module works across releases.


Here's some good reading material for kABI and the Driver Update Program: http://people.redhat.com/jcm/el6/dup/docs/dup_book.pdf




Senior Technical Support Engineer

Red Hat

You might also want to check out the RHEL Application Compatability Specification document that was updated for RHEL 6:







Red Hat, Inc.