Linux Device Drivers

Version Control in Modules

One of the main problems with modules is their version dependency, which was introduced in Section 2.2.1, in Chapter 2. The need to recompile the module against the headers of each version being used can become a real pain when you run several custom modules, and recompiling is not even possible if you run a commercial module distributed in binary form.

Fortunately, the kernel developers found a flexible way to deal with version problems. The idea is that a module is incompatible with a different kernel version only if the software interface offered by the kernel has changed. The software interface, then, can be represented by a function prototype and the exact definition of all the data structures involved in the function call. Finally, a CRC algorithm can be used to map all the information about the software interface to a single 32-bit number.^[29]

The issue of version dependence is thus handled by mangling the name of each symbol exported by the kernel to include the checksum of all the information related to that symbol. This information is obtained by parsing the header files and extracting the information from them. This facility is optional and can be enabled at compilation time.

For example, the symbol printk is exported to modules as something like printk_R12345678 when version support is enabled, where 12345678 is the hex representation of the checksum of the software interface used by the function. When a module is loaded into the kernel, ...