Linux Kernel Architecture

Chapter7:Modules

Dependencies between modules can make the situation extremely complex during dynamic extension of

the kernel if users are not aware of the specific structure of the inter-module dependencies. Whereas in

our example this does not present a problem, or at least not for interested and technically versed users, it

can be very laborious to find the correct module loading sequence if there are complex dependencies. A

means of automatically analyzing the dependencies between modules is therefore required.

Thedepmodtool in themodutilsstandard tool collection is used to calculate the dependencies between

the modules of a system. The program usually runs each time the system is booted or after new modules

have been installed. The dependencies found are stored in a list. By default, they are written to the file

/lib/modules/version/modules.dep. The format is not complicated; the name of the binary file of the

module is noted, and this is followed by the filenames of all modules that contain code needed for correct

execution of the module first named. The entry for thevfatmodule therefore looks like this:

wolfgang@meitner>cat modules.dep| grep vfat

/lib/modules/2.6.24/kernel/fs/vfat/vfat.ko: /lib/modules/2.6.24/kernel/fs/fat/fat.ko

This information is processed bymodprobe, which is used to insert modules into the kernel if existing

dependencies are to be resolved automatically. The strategy is simple:modprobereads in the contents of

the dependency file, searches for the line in which the desired module is described, and compiles a list of

prerequisite modules. Because these modules may, in turn, depend on other modules, a search is made

for their entries in the dependency file, and then the entries are checked; this procedure is continued until

the names of all prerequisite modules are known. Theactual task of inserting all modules involved into

the kernel is delegated to theinsmodtool.^7

The most interesting question still remains unanswered. How can dependencies between modules be

identified? To solve this problem,depmodemploys no special features of kernel modules but simply uses

the information shown above. This information can be read not only from modules but also from normal

executable files or libraries usingnm.

depmodanalyzes the binary code of all available modules, generates a list for each that includes all defined

symbols and all unresolved references, and finally compares these lists with each other. If module A

contains a symbol that is found in module B as an unresolved reference, this means that B depends on

A — and this fact will be duly acknowledged by means of an entry in the formB: Ain the dependency

file. Most symbols to which the modules refer are not defined in other modules but in the kernel itself.

For this reason, the file/lib/modules/version/System.mapis generated (likewise usingdepmod)when

modules are installed. This file lists all symbols exported by the kernel. If it contains an unresolved

symbol of a module, this is not a problem because it will be resolved automatically when the module is

loaded. If the symbol cannot be found in the file or in another module, the module may not be added into

the kernel because it refers to externalfunctions not implemented anywhere.

7.2.3 Querying Module Information

Additional sources of information are text descriptions that specify the purpose and usage of modules

and are stored directly in the binary files. They can be queried using themodinfotool in themodutils

distribution. Various items of data are stored:

❑ Author of the driver, usually with an e-mail address. This information is useful, particularly for

bug reports (besides granting the developer some personal satisfaction).

❑ A brief description of the driver function.

(^7) It is, of course, also necessary to check whether a module is already resident in the kernel — logically, it need not then be added.