Elementary Version Control

Some indispensable version control information is always stored in the .modinfo section, regardless of whether the version control feature is enabled or disabled. This allows a distinction to be made between various kernel configurations that have a drastic impact on the entire code and therefore need a separate set of modules. The following code is linked into each module during the second phase of module compilation:

module.mod.c

MODULE_INFO(vermagic, VERMAGIC_STRING);

vermagic_string is a string that indicates the key features of the kernel configuration: <vermagic.h>

#define VERMAGIC_STRING \ UTS_RELEASE " " \

MODULE_VERMAGIC_SMP MODULE_VERMAGIC_PREEMPT \ MODULE_VERMAGIC_MODULE_UNLOAD MODULE_ARCH_VERMAGIC

A copy of vermagic_string is stored in the kernel itself and in each module; a module may only be loaded if both variants match. This means that the following must be identical in the module and in the kernel:

□ The SMP configuration (enabled or not)

□ The preemption configuration (enabled or not)

□ The compiler version used

□ An architecture-specific constant

On IA-32 systems, the processor type is used as the architecture-specific constant because some very different features are available. For example, a module compiled with special optimization for Pentium 4 processors cannot be inserted into an Athlon kernel.

The kernel version is stored but is ignored when the comparison is made. Modules with different kernel versions whose remaining version string matches can be loaded with no problem; for example, modules of 2.6.0 can be loaded into a kernel with version 2.6.10.

Continue reading here: Inserting Modules

Was this article helpful?

0 0