Pick a Free OS

Introduction to Linux kernel modules

Lets now discuss the demand loading of the module by the kernel, dynamically. When the Linux kernel discovers the need for a module, the kernel requests to the kernel daemon (kerneld) to load the appropriate module. To illustrate this with an example, lets mount a NTFS partition in the Linux system. If the NTFS filesystem support is not statically implemented in the kernel (but compiled as a module), the kernel daemon will search for the appropriate module and load it from the repository. Then the partition is mounted for the use.

Lets go deep into the action of the kernel daemon (kerneld). The kerneld is the normal user process having exclusive superuser privileges. At the time of booting, kerneld opens the IPC channel to the kernel and uses it for transferring messages (request for loading modules), to and from the kernel. While loading the module, the kerneld calls modprobe and insmod to load the required module. The insmod utility should able to access the requested module. The demand loadable kernel modules are usually located at /lib/module/ directory as the object files linked as relocatable images.

Let us revisit the working of the insmod to get a clear picture of the module loading operation. The insmod depends on some critical system calls to load the module to the kernel. It uses the sys_create_module to allocate kernel memory to hold module. It uses get_kernel_syms system call to get the kernel symbol table in order to link the module. It then calls the sys_init_module system call to copy the relocatable object code of the module to the kernel space. And soon after this, insmod calls the initialization function of the concerned module i.e. init_module. All of these system calls can be found in kernel/module.c.

Unloading modules

The modules can be unloaded using rmmod command. While removing modules, rmmod ensures the restriction that the modules are not in use and they are not referred by any other module or the part of the kernel. The demand loaded modules (i.e. the modules loaded by kerneld) are automatically removed from the system by `kerneld' when they are no longer used. Every time it's idle, timer expires and kerneld makes a system call requesting for all the demand loaded kernels, which are not busy to be removed. The modules, whose visited flags are cleared and marked as AUTOCLEAN, are `unloaded'.



Technically, no, this introductory course won't cover the intricacies of device drivers but let me expand on that.

This course is meant to be an introduction to the basics of kernel programming; that is, it's going to cover the foundations of what every beginning kernel programmer needs to know in terms of kernel structure, configuring and building a new kernel, how to write loadable kernel modules, transferring data between user space and kernel space, simple debugging and so on. Clearly, none of that represents writing an actual device driver, but it's all essential information you'll need when you want to start writing specific types of drivers.

There are already plans for followup courses such as "How to write a PCI driver" and "How to write a USB driver", courses that will (probably) consist of perhaps a dozen lessons each and will cost about the same amount as this introductory course (or maybe slightly less, depending on length).

So if you feel that you already know kernel programming at a basic level, you can just wait for the driver course you're interested in. On the other hand, if you're truly new to kernel programming, you will probably need this intro course as a lead-in to the driver course.