Linux Kernel Architecture

Chapter7:Modules

is perfectly adequate to program standard drivers — if, however, the module wants to delve deeply into

the depths of the kernel, it must use other functions, and with some licenses this is prohibited for legal

reasons. Themodprobetool must take this situation into consideration when new modules are used. This

is why it checks the licenses and rejects illegal link actions.

Most developers (and also users) are not particularly happy about the fact that some manufacturers

distribute their drivers in binary modules. This not only makes it difficult to debug kernel errors, but also

has an adverse effect on ongoing driver development because it is necessary to rely on manufacturers to

eliminate bugs or implement new functions. At this point, it is not my intention to waste your time with

the many and varied aspects of manufacturer behavior. I simply refer you to the countless discussions

that have taken place, are still taking place, and will doubtless take place in the future on the various

Internet channels (not least on the kernel mailing list, see Appendix F).

7.2.4 Automatic Loading

Generally, module loading is initiated from userspace, either by the user or by means of automated

scripts. To achieve greater flexibility in the handling of modules and to improve transparency, the kernel

itself is also able to request modules.

Where is the catch? It is not difficult for the kernel to insert the binary code once it has access to it. How-

ever, it cannot do this without further help from userspace. The binary file must be localized in the

filesystem, and dependencies must be resolved. Because this is far easier to do in userspace than in ker-

nel space, the kernel has an auxiliary task known askmodto which these tasks are delegated. Note that

kmodis not a permanent daemon, but is only initiated by the kernel on demand.

Let us examine a scenario that demonstrates the advantages of kernel-initiated module loading. It is

assumed that the VFAT filesystem is available as a module only and is not permanently integrated into

the kernel. If a user issues the following command for mounting a diskette:

wolfgang@meitner>mount -t vfat /dev/fd0 /mnt/floppy

beforethevfatmodule is loaded into the kernel, an error message would normally be returned indicating

that the corresponding filesystem is not supported because it is not registered with the kernel. However,

in practice this is not the case. The diskette is mounted without any problem, even if the module is not

loaded. When themountcall terminates, the required modules are located in the kernel.

How is this possible? When the kernel processes themountsystem call, it discovers that no information

on the desired filesystem — vfat — is present in its data structures. It therefore attempts to load the corre-

sponding module using therequest_modulefunction whose exact structure is discussed in Section 7.4.1.

This function uses thekmodmechanism to start themodprobetool, which then inserts thevfatmodule in

the usual way. In other words, the kernel relies on an application in userspace that, in turn, uses kernel

functions to add the module as illustrated in Figure 7-2.

Once this has been done, the kernel again tries to obtain information on the desired filesystem; as a result

of themodprobecall, this information is now held in its data structures if, of course, the module actually

exists — if not, the system call terminates with a corresponding error code.