KernelModulePackages
From KernelDrivers
←Older revision | Newer revision→
Kernel Module Packages
Linux is a complex and evolving Operating System and as such is a moving target with respect to its internal interfaces. Traditionally, drivers have had to be built for a particular kernel version (for example 2.6.x.y-vendorversion) and had a close affinity with a given binary kernel package. The use of kernel module versioning allows some flexibility however end-users typically don't know if a given compiled driver module will work with a different kernel version until they try to load the driver for themselves. By providing additional versioning information at package installation time, it is possible to know ahead of time whether a given driver will work with a particular kernel, while allowing the user some flexibility to upgrade a kernel to a newer/modifed version retaining binary interface (ABI) compatibility.
There are some limitations of which you should be aware. kABI compatibility between given upstream kernel releases can never be assured (there is no stable kABI upstream) however various vendors provide levels of compatibility in their commercially shipping products. Despite the large number of changes happening upstream on a regular basis, the mainstream Linux kernel won't differ too drastically between minor releases either, so this technology is often useful when tracking minor update kernels even in distributions that don't try to maintain a level of binary compatibility between kernels - for example a new -stable kernel release that fixes a security vulnerability. This can help to avoid waiting for third party drivers to be updated.
The typical use case for KMPs is for supplying updated drivers after a Linux distribution has been shipped. Driver updates are wrapped up with dependency information such that they may continue to work when the kernel itself is later upgraded (for example, for a security fix). Most importantly, the end-user knows ahead of time if a security upgrade is going to require an updated driver module as their package management software can automate the dependency resolution process - making it much easier to handle vast numbers of machines with custom/updated drivers without having to constantly rebuild drivers.
There are two semi-compatible implementations of Kernel Module Packages currently under development:
An aim of this project is to ensure a level of capatibility between the two implementations without needlessly re-inventing the wheel (other distributions may choose to get involved). Ideally, a driver writer will be able to write to a common SPEC file format when building their RPMs - although the behind-the-scenes details will in fact differ. The intention is to provide this compatibility through a common set of RPM macros. We're hoping to eventually produce a "de facto" KernelModulePackageStandard that offers enough shared functionality, while allowing vendors (and developers) to provide their own extensions as necessary, though that's for the future.
