Linux Kernel Architecture

Chapter7:Modules

in the kernel, regardless of whether the code was generated dynamically by modules or is permanently

compiled into the kernel.

modprobealso accessesinsmodinternally once it has identified the additional modules needed for the

desired module. Before discussing how this is implemented, I will first describe the mode of operation of

insmodon which work with modules in userspace is based.

The actions needed when loading a module show strong similarities with the linking of application

programs by means ofldand with the use of dynamic libraries withld.so. Externally, modules are just

normal relocatable object files, as afilecall will quickly confirm:

wolfgang@meitner>file vfat.ko

vfat.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

They are, of course, neither executable files nor program libraries as normally found in system program-

ming; however, the basic structure of the binary module file is based on the same scheme also used for

the above purposes.

The output of thefilecommand indicates that the module file isrelocatable, a familiar term in userspace

programming.Relocatablefiles have no function references to absolute addresses but point only torelative

addresses within the code and can therefore be loaded at any offsets in memory provided the addresses

are modified accordingly by the dynamic linkerld.so. The same applies for kernel modules. Addresses

are again given in relative and not absolute units. However, it is the kernel itself and not the dynamic

loader that performs relocation.

Whereas in earlier kernel versions (up to 2.4) modules had to be loaded in a multistep process (reser-

vation of memory in the kernel, followed by relocation of data in userspace and copying of the binary

code into the kernel), only one system call —init_module— is now needed to perform all actions in the

kernel itself.

When the system call is processed, the module code is first copied from the kernel into kernel memory;

this is followed by relocation and the resolution of as yet undefined references in the module. These occur

because the module uses functions that are permanently compiled into the kernel and whose addresses

are not known at compilation time.

Handling UnresolvedReferences

In order to work with the remaining parts of the kernel, modules must use functions provided by the

kernel. These may be general auxiliary functions such asprintkorkmallocused by almost every ker-

nel part. More specific functions associated with the module functionality must also be used. Theramfs

module enables a filesystem to be made available in memory (usually known as RAM disk) and must

therefore — like any other code used to implement file systems — call theregister_filesystemfunc-

tion to add itself to the list of available filesystems in the kernel. The module also makes use of (among

others) thegeneric_file_readandgeneric_file_writestandard functions that are present in the

kernel code and that are used by most kernel filesystems.

A similar situation arises when libraries are used in userspace. Programs use functions defined in

an external library by storing pointers to the functions — but not the implementation of the function

itself — in their own binary code (of course, other symbol types such as global variables can appear

instead of functions). References are resolved for static libraries when the program is linked (usingld)

and for dynamic libraries when the binary file is loaded (usingld.so).