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.


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:

provide a proper from module-init-tools:
Early boot tools, installers, driver install disks want to access
information about available modules to optimize bootup handling.

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):

	struct kmod_ctx *ctx = kmod_new(NULL, NULL);
	struct kmod_module *mod;
	kmod_module_new_from_name(ctx, name, &mod);
	kmod_module_insert_module(mod, 0, NULL);


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.


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.


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.


The repository for this project is located at

Package with kmod 1 source code can be downloaded from:


Last I’d like to thank Kay Sievers for his support in reviewing code, giving advices and helping to design kmod.

15 thoughts on “ANNOUNCE: kmod 1”

  1. This is great!

    I know a blog isn’t bugzilla, but I don’t see a bug tracker — how about some Python bindings? :-)

    Again, great stuff!

    1. One of the guys making kmod with me really likes python and doing bindings for it. Our company made some bindings already (e.g. EFL) so maybe we can add it once the API is mature enough.

  2. Beware that the kmod-* namespace is already used on RHEL/CentOS/Scientific Linux for kABI compliant kernel module packages. Which means that hundreds of packages exist that start with kmod-.

    So it would be wise to not release a project within the kmod-* namespace in order not to be confused with kernel module packages.

    See for a list of existing kmod-packages in their repository…

    1. 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.

      Also, initial Fedora package was posted for playing:


Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>