Previous Next Table of Contents

8. Kernel modules

I think I don't have to explain why are there modules in the Linux kernel and why you should try to modularize your drivers. So I'll focus on the differences in writing modules which were introduced in recent kernels. All the module macros are defined in <linux/module.h>, so you should include this header into all possible modularized sources. Current kernel uses extensively ELF sections for most of the module stuff, so everything has been greatly simplified. If you are writing a new module, you can spend a couple of seconds in declaring MODULE_AUTHOR(), MODULE_DESCRIPTION(), maybe MODULE_SUPPORTED_DEVICE(). All these macros take a string, which then can be used by module utilities. Unlike with older kernels, new kernels come with support for explicit module parameters. With older kernels, one could assign assign value to all global variables in the module. Recent kernels give you control on the exported variables, you can specify their type and sizes of variable arrays. For each variable you want to make user settable, you need one MODULE_PARM() macro and optionally one MODULE_PARM_DESC() macro. The MODULE_PARM() macro takes two arguments, one is the name of the variable you want to export (the same name will users use on the module command line), the latter is a string describing variable types. For a single variable, you use letters b, h, i, l, s for char, short, int, long and string variable. Additionally, if you want to export a vector of variables of the same type, you prefix this letter with a string of the form min[-max], where min is minimum number of variables the user has to set, optional max tells the maximum number of variables user can set. Like that you can create structures with most important variables at the beginning, so that the user can change e.g. only first 4 of the 8 parameters in total and leave defaults for the rest.

Other useful macros that you could be used to from older kernels as well, are MOD_INC_USE_COUNT and MOD_DEC_USE_COUNT (and their __MOD_INC_USE_COUNT, __MOD_DEC_USE_COUNT counterparts). You should find a good place in your code, such that the usage count will be zero when the module is not used at all, but never goes below zero. Macros without leading underscores increment or decrement current module's usage count, underscored macros take as argument module, which the usage counter should be changed to.

A module is a partly relocated ELF object. Before it can be inserted into the kernel, insmod has to relocate it fully, so that no symbols are left undefined. During relocation, only specially exported symbols from kernel and already loaded modules will be used for the relocation. Exporting a symbol from the kernel takes precious kernel space, so not all kernel symbols should be exported. When you wish to use some not yet exported symbol in your module, you should think if there are alternate solutions that will avoid using unexported symbols and export new symbols only when really necessary. On the other side, one should export symbols because they are generally useful, not because module XY needs to use


Previous Next Table of Contents