Primary Menu

ANNOUNCE: kmod 1

For some weeks now I and Gustavo Barbieri at ProFUSION have been working on a new library and a set of tools, libkmod and kmod respectively. This is the announcement of its first public release.

Overview

The goal of the new library libkmod is to offer to other programs the needed flexibility and fine grained control over insertion, removal, configuration and listing of kernel modules. Using the library, with simple pieces of code it’s possible to interact with kernel modules and then there’s no need to rely on other tools for that. This is a thing lacking on Linux for a while and it’s one of the items in the Plumber’s Wish List for Linux. Quoting it:

We went one step further and not only we are able now to give an API to load and remove kernel module, but also all the other common operations are being added to this API. The first user for this API will be udev. In a recent Linux Desktop (and also several embedded systems) when computer is booting up, udev is responsible for checking available hardware, creating device nodes under /dev (or at least configuring their permissions) and loading kernel modules for the available hardware. In a kernel from a distribution it’s pretty common to put most of the things as modules. Udev reads the /sys filesystem to check the available hardware and tries to load the necessary modules. This translates in hundreds of calls to the modprobe binary, and in several of them just to know the module is already loaded, or it’s in-kernel. With libkmod it’s possible for udev with a few lines of code to do all the job, benefiting from the configurations and indexes already opened and parsed. We’ve been talking to Kay Sievers (udev’s mantainter) and Lennart Poettering (systemd’s maintainer) regarding this and we are looking forward to have udev using libkmod soon.

Example code:

To insert a module by name without any options and strange configurations it’s sufficient to do as following (without treating errors for easy of comprehension – see the documentation for possible errors):

Tools

Besides doing the library, we are re-designing the module-init-tools tools on top of the new API we created. With this first version we are already providing compatible binaries for lsmod, rmmod, insmod and modprobe, the last one with some functionality missing. Next versions we plan to fill the gaps with the provided tools and provide all the others like depmod and modinfo.

License

We try to avoid issues regarding licences: the library is licensed under “LGPLv2 or later” and the tools are under “GPLv2 or later”. There’s still lots of work to be done and places to optimize. We greatly appreciate contribution from other developers.

Roadmap

The API is not set on stone and is going to suffer some changes in future releases as we see fit to finish implementing all the tools. Below is the list of the features already implemented

kmod 1

libkmod provides the necessary API for:

List modules currently loaded

Get information about loaded modules such as initstate, refcount, holders, sections, address and size

Lookup modules by alias, module name or path

Insert modules: options from configuration and extra options can be passed, but flags are not implemented, yet

Remove modules

Filter list of modules using blacklist

For each module, get the its list of options and install/remove commands

Indexes can be loaded on startup to speedup lookups later

Tools provided with the same set of options as in module-init-tools:

kmod-lsmod

kmod-insmod

kmod-rmmod

kmod-modprobe, with some functionality still missing (use of softdep, dump configuration, show modversions)

Following is a rough roadmap for future releases:

kmod 2

Provide the API for features missing in kmod-modprobe, namely: dump configuration and indexes, soft dependencies, install and remove commands. Features relying on ELF manipulation will still be missing;

Provide all the tools available in module-init-tools. Some of them like depmod may be entirely copied from module-init-tools for later convertion;

kmod 3

Provide a single kmod tool that will abstract all the others, accepting commands like “kmod list”, “kmod remove”, “kmod insert”. Distributions may then use symlinks from current tools to the kmod binary and we can kill the ‘kmod-*’ test tools that we are introducing in kmod 1;

We thoroughly test the features implemented in kmod, but like any other software it’s possible to contain bugs that we didn’t find; we may decide to release new versions between the versions above and then this numbers change. Otherwise kmod 2 will already be sufficient for udev to pick it up as a dependency and start benefiting from the fine grained control over its operations with kernel modules.

Yea. I brought this up as a concern (the kmod-* prefix) but was reassured that actually it makes some sense. After all, now anything to do with modules is kmod*something, and that’s not necessarily bad. If people really complain, something could change.