What Is A Kernel Module?

What Is A Kernel Module?

So, you want to write a kernel module. You know C, you've written a few normal programs to run as processes, and now you want to get to where the real action is, to where a single wild pointer can wipe out your file system and a core dump means a reboot.

What exactly is a kernel module? Modules are pieces of code that can be loaded and unloaded into the kernel upon demand. They extend the functionality of the kernel without the need to reboot the system. For example, one type of module is the device driver, which allows the kernel to access hardware connected to the system.

Without modules, we would have to build monolithic kernels and add new functionality directly into the kernel image. Besides having larger kernels, this has the disadvantage of requiring us to rebuild and reboot the kernel every time we want new functionality.

How do these modules find their way into the kernel?

When the kernel needs a feature that is not resident in the kernel, the kernel module daemon kmod execs modprobe to load the module in. modprobe is passed a string in one of two forms:

A module name like mislinuxdog or ppp

A more generic identifier like char−major−10−30

If modprobe is handed a generic identifier, it first looks for that string in the file

/etc/modprobe.conf If it finds an alias line like:

alias char−major−10−30 mislinuxdog

it knows that the generic identifier refers to the module mislinuxdog.ko.

Next, modprobe looks through the file /lib/modules/version/modules.dep, to see if other modules must be loaded before the requested module may be loaded. This file is created by depmod −a and contains module dependencies. For example, msdos.ko requires the fat.ko module to be already loaded into the kernel. The requested module has a dependency on another module if the other module defines symbols (variables or functions) that the requested module uses.

Lastly, modprobe uses insmod to first load any prerequisite modules into the kernel, and then the requested module. modprobe directs insmod to /lib/modules/version/, the standard directory for modules.

insmod is intended to be fairly dumb about the location of modules, whereas modprobe is aware of the default location of modules, knows how to figure out the dependencies and load the modules in the right order. So for example, if you wanted to load the msdos module, you'd have to either run:

insmod /lib/modules//lib/modules/3.10.0-862.11.6.el7.x86_64/kernel/fs/fat/fat.ko

insmod /lib/modules//lib/modules/3.10.0-862.11.6.el7.x86_64/kernel/fs/msdos/msdos.ko

or:

modprobe msdos

What we've seen here is: insmod requires you to pass it the full pathname and to insert the modules in the right order, while modprobe just takes the name, without any extension, and figures out all it needs to know by parsing /lib/modules/version/modules.dep.

Linux distros provide modprobe, insmod and depmod as a package called module−init−tools. In previous versions that package was called modutils. Some distros also set up some wrappers that allow both packages to be installed in parallel and do the right thing in order to be able to deal with 2.4 and 2.6 kernels. Users should not need to care about the details, as long as they're running recent versions of those tools.

Now you know how modules get into the kernel. There's a bit more to the story if you want to write your own modules which depend on other modules (we're calling this `stacking modules'). But this will have to wait for the next article. I have a lot to cover before addressing this relatively high−level issue.