Constantly changing kernel sources naturally has implications for driver and module programming — particularly in the context of proprietary binary-only drivers; and it is these implications that are discussed in this section.
When new features are implemented or overall design is revised, it is often necessary to modify the interfaces between the individual parts of the kernel to cope with the new situation or to support a range of performance and design improvements. Of course, developers do their best, whenever possible, to restrict changes to internal functions not directly used by drivers. However, this does not rule out occasional modifications to the "public" interfaces. Naturally, the module interface is also affected by such changes.
When drivers are made available in the source code, this does not present a problem so long as an industrious kernel hacker can be found to adapt the code to the new structures — with most drivers, this can be done in a matter of days (if not hours). Since there is no explicit "development kernel'' anymore, it is unavoidable that interface changes are introduced between two stable revisions of the kernel, but since the in-tree code can be easily updated, this does not pose a particular problem.
The situation is different with drivers distributed by manufacturers in binary only. Users are forced to rely on the goodwill of the manufacturers and must wait until a new driver has been developed and released. This approach gives rise to a whole range of problems, two of which are technical 23 and therefore of particular interest to us:
□ If the module uses an obsolete interface, not only is correct module functioning impaired, but also there is a great likelihood that the system will crash.
□ Because the interfaces differ for SMP and single-processor systems, two binary versions are needed, and again this can cause the system to crash if the wrong one is loaded.
Of course, these arguments also apply if Open Source modules in binary only are used. Sometimes, this is the only option available to technically less experienced users until manufacturers offer an appropriate update.
23There is a wealth of detailed information on moral, ethical, and ideological issues on the Internet.
The need for module version control is therefore apparent. But which is the best approach? The simplest 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 interface not used 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.
Continue reading here: Checksum Methods
Was this article helpful?