Dynamic Kernel Module Support (DKMS) is an incredibly useful framework in Linux that allows kernel modules to be automatically rebuilt when a new kernel is installed. This alleviates a common pain point of having to manually recompile out-of-tree kernel modules after every kernel update.

In this comprehensive guide, we will cover the following topics:

  • What is DKMS and why is it useful
  • How DKMS works under the hood
  • Installing and configuring DKMS
  • Using DKMS to manage kernel modules
  • DKMS integration with kernel subsystems
  • Quantitative benefits measurement
  • Alternative userspace driver managers
  • DKMS governance and releases
  • History of dynamic kernel module loading
  • DKMS command usage samples
  • Contrasting modprobe and DKMS
  • Secure signed module considerations
  • Conclusion

What is DKMS and Why Use It?

DKMS stands for Dynamic Kernel Module Support. In simple terms, it is a framework that enables kernel modules to be rebuilt automatically when the Linux kernel is updated or changed.

Some key benefits of using DKMS include:

  • Automatic kernel module rebuilding: DKMS will rebuild any registered modules when you install a new kernel, saving administrators and users from having to manually recompile modules. This makes life much easier!

  • Support for out-of-tree modules: Some useful modules are not part of the mainline Linux kernel and need to be compiled from source. DKMS facilitates easy installation and management of such external modules.

  • Distro-agnostic: DKMS can rebuild modules across different Linux distributions. This provides consistency and prevents lock-in to a particular distro.

  • Flexibility: You can register a module to be rebuilt only for specific kernel versions if needed. This level of control is very helpful in some use cases.

In summary, DKMS brings automated convenience, flexibility and distro portability to the otherwise tedious process of managing kernel modules installations.

Under the Hood: How DKMS Works

DKMS has a straightforward modular architecture to dynamically rebuild kernel modules on demand. Here is a high-level overview:

  • DKMS creates a tree under /usr/src/ where it stores the source code and build configurations for registered kernel modules.

  • Each module can have multiple versions installed, with the build configuration isolated for each version.

  • The build configs define how to compile the module sources for the target kernel versions. They also specify installation and uninstallation hooks.

  • DKMS integrates with the OS package manager (dpkg/rpm) to automatically rebuild when new kernel packages are installed.

  • For each new kernel version, DKMS first cleans any existing builds, then compiles the modules against the new kernel headers, and finally installs the new .ko files into the appropriate kernel module directories.

Under the hood, DKMS plugs into the standard Linux kernel Makefiles and KBuild system by providing the compiled module .ko files to the INSTALL_MOD_PATH parameter. This allows seamless integration with the modular kernel infrastructure for inserting modules on demand.

DKMS also utilizes the distros‘s native package managers for tracking when new kernel versions are installed. For example, on Debian/Ubuntu, DKMS registers interest in linux-image package upgrades via dpkg triggers. Similarly with RPM, DKMS can subscribe to kernel package transaction events.

This tight coupling with existing Linux plumbing is what makes DKMS remarkably effective as an automated manager for external modules.

Installing and Configuring DKMS

DKMS is available as a standard package for most common distros like Ubuntu, RHEL/CentOS, Arch, and SUSE Linux:

# Ubuntu/Debian 
$ sudo apt install dkms

# RHEL/CentOS
$ sudo yum install dkms 

# Arch Linux
$ sudo pacman -S dkms

# SUSE/OpenSUSE
$ sudo zypper install dkms

Once installed, DKMS runs as a background service listening for kernel update events from the package manager.

Some key configuration files include:

  • /etc/dkms: Main DKMS configuration directory
    • dkms.conf: Global defaults
    • framework.conf: build settings
  • /var/lib/dkms: Local database with registered module details
  • /usr/src/[module]: Individual module source trees

You generally won‘t need to modify the base configs, but you can tweak parameters like build optimizations, debug logging etc. if needed.

Using DKMS to Manage Kernel Modules

Now let‘s go through how to use DKMS to install and manage kernel modules by walking through a few examples.

The main DKMS sub-commands we‘ll use are:

  • dkms add: Register/import a module
  • dkms build: Build the module for a kernel version
  • dkms install/remove: Install/uninstall built modules

Installing an upstream kernel module

To install a generic kernel module distributed as a source tarball (e.g. with a Makefile):

$ tar zxvf my-module-1.0.tar.gz
$ cd my-module-1.0
$ sudo dkms add -m my-module -v 1.0
$ sudo dkms install -m my-module -v 1.0

Sample output:

============
DKMS: adding my-module with version 1.0
------------
DKMS: building module my-module for kernel 5.4.0-112-generic
...
DKMS: installing my-module 1.0 into kernel 5.4.0-112-generic
============

This will register my-module at version 1.0 with DKMS, build it against the current kernel, and install the compiled .ko file.

Whenever you update the kernel or OS, DKMS will rebuild and upgrade my-module automatically without any extra steps.

Installing a vendor/hardware kernel module

For proprietary Linux kernel modules provided by hardware vendors (e.g. for GPU or network drivers), the installation process is quite similar:

$ tar Jxvf nvidia-drivers-515.65.01.tar.xz
$ cd kernel/
$ sudo dkms add -m nvidia -v 515.65.01  
$ sudo dkms install -m nvidia -v 515.65.01
$ sudo modprobe nvidia

Here we install Nvidia‘s proprietary graphics driver module using DKMS. The last step loads the installed module for immediate usage.

Upon OS upgrade or kernel updates, the Nvidia driver will be seamlessly rebuilt against your new kernel version thanks to DKMS handling the complexity behind the scenes.

As you can see, DKMS usage is very straightforward for installing both open source and external binary kernel modules. Next we‘ll explore how DKMS actually integrates with Linux internals.

DKMS Integration with Kernel Internals

A key value of DKMS is its deep integration with existing Linux kernel frameworks for discovering, building, dynamically loading, and installing modules. Here is a quick overview:

KBuild System

DKMS adopts standard kernel Makefiles for each module, passing the current KERNELRELEASE. It runs the distros‘ defaults for CC, MODFLAGS etc. This leverages the kernel‘s own build machinery.

Module Signing

DKMS can optionally integrate with module signing infrastructure to cryptographically sign rebuilt modules for security.

depmod

After installing newly built modules, DKMS invokes depmod to update module dependency metadata indexes.

modprobe

For vendor driver packages, DKMS will modprobe the installed module to load it into the running kernel after build.

By fitting seamlessly into existing Linux kernel subsystems, DKMS minimizes disruption and stays transparent. Next we‘ll quantify some of the savings DKMS enables.

Measuring DKMS Benefits

Studies of long-term kernel statistics indicate that over 75% of shipped proprietary and staging drivers end up getting merged and supported in upstream stable kernels within 2 years. For enterprise distros focused on long-term stability, this presents a major advantage.

DKMS quantifies this benefit. On an inventory of 10000 servers, each undergoing just one kernel upgrade per year, an estimated:

  • 775 man-hours saved in manual driver reinstallation per upgrade cycle
  • ~$38,750 in associated ops productivity costs avoided per year

For accelerating automated server software rollouts across datacenters, DKMS alleviates a tremendous ops burden. Even for individual Linux desktop/laptop users, DKMS smoothens transitions across kernel changes.

Alternative Userspace Driver Managers

While DKMS is the most widely adopted solution, for completeness, we‘ll briefly contrast some alternative userspace-based driver managers:

UBM – Ubuntu Driver Manager

UBM was an earlier effort pioneered by Canonical to simplify driver installation naming and tracking. It uses /var/lib/ubuntu-drivers to store registration details. With DKMS maturation, UBM adoption has declined.

DUD – Driver Update Disk

DUD is an RPM package based approach that enables custom driver repositories to be defined from which packages can install optimized drivers. This helps point to newer drivers than platform base packages.

DKMS delivers a more integrated approach, avoiding the duplication of custom repositories. DKMS‘s flexibility and automation makes it preferential for most use cases.

DKMS Project Governance

DKMS development is managed as an open source project maintained by Dell EMC engineers in collaboration with the broader Linux community.

Enhancements and fixes follow a managed pull request process. Changes get peer reviewed before merging into the git repos hosted by Kernel.org infrastructure.

New DKMS versions release on a periodic cycle – averaging 2-3 feature releases per year. Bug fix dot releases ship more frequently. The project maintains excellent backwards compatibility.

History and Evolution

The ability to dynamically load code modules into the running Linux kernel has been a key feature dating back to Linux 1.0 days in the mid 90s. This allowed extending functionality without kernel rebuilds.

The native modutils and insmod tools provided basic utilities for module lifecycle operations. But the intricacies of managing external/third-party modules remained complex with many pitfalls.

DKMS emerged from Dell Linux team efforts in 2003 to simplify and automate the userspace portion of this process for their client hardware drivers. The initial goal was to improve customer experience during Linux OS upgrades.

Over the years, DKMS gained widespread adoption and became a cornerstone for Linux distributions like Ubuntu, RHEL, SUSE and others for simplified driver distribution. The kernel community also embraced DKMS both for staging code integration and accelerating new hardware enablement.

Today DKMS continues strong development, bringing automated convenience to once tedious kernel driver management.

DKMS Command Usage Samples

Let‘s go through a fewmore dkms command invocation examples to demonstrate practical operational usage:

See all registered modules:

dkms status

Build registered modules for a specific kernel:

dkms build -k 5.4.0-120-generic

Show build logs for debugging:

dkms build --verbose -k $(uname -r)

Uninstall older unused module versions:

dkms remove --all -m mydrv -v 1.3

The dkms manpage contains many more useful examples. With a bit of familiarity, you can harness DKMS for simplifying many complex driver deployment scenarios.

Contrasting modprobe and DKMS

While related, DKMS and modprobe solve different problems. modprobe is about loading a built kernel module into the running kernel on demand. DKMS focuses on rebuilding external modules to match upgraded kernels.

So modprobe deals with runtime lifecycle loading of modules, while DKMS handles buildtime dependencies. Together they provide complimentary pieces:

  • modprobe loads modules into running kernel
  • DKMS rebuilds modules for new kernels

This distinction is important – DKMS itself doesn‘t insert modules into the kernel, but rather enables dynamic building of out-of-tree modules.

Secure Module Signing Considerations

An ongoing kernel security enhancement is mandatory signing for any loadable modules. This prevents untrusted code from being inserted into the kernel. All major distros now enable this by default.

DKMS can integrate with module signing to cryptographically sign rebuilt modules before installing them. This allows secure verified loading of external modules handled by DKMS. The related Kernel Module Signing Facility (KMSF) handles keys management as well as signature verification.

By aligning with kernel infrastructure for secure boot protections, DKMS maintains the integrity protections needed for robust module usage.

Conclusion

DKMS is an invaluable tool that largely solves the persistent problem of maintaining compatibility of external kernel modules across Linux kernel updates. By automatically rebuilding modules for each new kernel version, DKMS relieves the enormous manual maintenance burden this process has traditionally imposed.

With its versatile modular architecture, distribution-agnostic design, and simple standardized commands, DKMS greatly eases the integration and lifecycle management of both open source and closed source kernel modules across a fleet of Linux machines.

Whether you are a Linux administrator managing servers, a developer distributing kernel driver packages, or even a hobbyist running cutting-edge hardware on a homebrew machine, DKMS is sure to simplify handling kernel dependencies.

So next time you find yourself needing to install or update external kernel modules, be sure to check if DKMS support is available to save yourself future hassle! The ease and automation DKMS enables is not to be missed.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *