Chapter7:Modules
The need for module version control is therefore apparent. But which is the best approach? The sim-
plest solution would be to introduce a constant stored in both the kernel and module. The value of the
constant would be incremented each time an interface changes. The kernel would not accept a module
unless the interface number in the module and in the kernel were identical; this would solve the version
problem. This approach works in principle but is not very intelligent. If an interfacenotused by a module
is changed, it can no longer be loaded although it would function perfectly.For this reason, a finely grained method is used to take account of changes in the individual
kernel procedures. The actual module and kernel implementation is not relevant. What is relevant
is that the call interface may not change if a module is to function with different kernel versions.^24
The method used is striking in its simplicity, but its mechanism is perfectly capable of solving
version control problems.7.5.1 Checksum Methods
The basic idea is to use a CRC checksum generated using the parameters of a function or procedure. The
checksum is an 8-byte figure that requires four lettersin hexadecimal notation. If the function interface
is modified, so is the checksum. This enables the kernel to deduce that the new version is no longer
compatible with the old version.The checksum is not a mathematically unique sum — (different procedures could be mapped to the same
checksum because there are more combinations (in fact, an infinite number) derived from procedure
parameters than there are checksums available (namely, 2^32 ). In practice, this is not a problem because
the likelihood that a function interface has the samechecksum after several of its parameters have been
changed is low.Generating a Checksum
Thegenksymtool that comes with the kernel sources and is automatically created at compilation time is
used to generate a function checksum. To demonstrate how it works, let’s use the following header file,
which contains an exported function definition:#include<linux/sched.h>
#include<linux/module.h>
#include<linux/types.h>int accelerate_task(long speedup, struct task_struct *task);EXPORT_SYMBOL(accelerate_task);The function definition contains a compound structure as a parameter, and this makes the work of
genksymsmore difficult. When the definition of the structure changes, the checksum of the function
also changes. In order to analyze the contents of the structure, it is a given that the contents must be
known. Consequently, input forgenksymsis made up exclusively of files that have been processed by the
pre-processor and therefore contain the required include files in which the appropriate definitions are
located.(^24) This presupposes, of course, that the name of the function changes when the semantics of its code change but that the interface
definition remains unchanged.