Pick a Free OS

Introduction to Linux kernel modules

Assuming that the module can be unloaded, the cleanup_module function of the concerned module is called to freeup the kernel resources it has allocated. After the successful execution of the cleanup_module, the module datastructure is marked DELETED and it is unlinked from the kernel and unlisted from the list of kernel modules. The reference list of the modules on which it (module removed) is dependent is modified and dependency is released. The kernel memory allocated to the concerned module is deallocated and returned to the kernel memory spool.

Version Dependency of modules

Version dependency of the module is one of the trickiest parts of the Linux Kernel Module programming. Typically, the modules are required to be compiled for each version of the kernel. Each module defines a symbol called kernel_version, which insmod matches against the version number of the current kernel. The current kernel 2.2.x/2.4.x define the symbol in . Hence if the module is made up of multiple source files, the should be included in only one of the source files.

Though typically, modules should be recompiled for each kernel version, it is not always possible to recompile module when it is run on as a commercial module distributed in binary form. Kernel developers have provided a flexible way to deal with the version problem. The idea is that a module is incompatible with a different kernel version only if the software interface offered by the kernel is changed. The software interface is represented by the function prototype and the exact definition of all the data structures involved in the function call. The CRC algorithm can be used to map all the information about software interface to the single 32bit number. The issue of version dependency is handled by using the name of the each symbol exported.



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.