Linux Kernel Architecture

(Jacob Rumans) #1

Chapter7:Modules


return 0;
return try_module_get(mod);
}

It is not complicated to establish the relation. A new instance ofmodule_use,whosemodule_which_uses
pointer is set to the module instance of A, is created. The newmodule_useinstance is added to thelist
list of B.

7.3.3 Binary Structure of Modules


Modules use the ELF binary format, which features several additional sections not present in normal
programs or libraries. In addition to a few compiler-generated sections that are not relevant for our
purposes (mainly relocation sections), modules consist of the following ELF sections^11 :
❑ The__ksymtab,__ksymtab_gpl,and__ksymtab_gpl_futuresections contain a symbol table
with all symbols exported by the module. Whereas the symbols in the first-named section can be
used by all kernel parts regardless of the license, symbols in__kysmtab_gplmay be used only
by GPL-compatible parts, and those in__ksymtab_gpl_futureonly by GPL-compatible parts in
the future.
❑ __kcrctab,__kcrctab_gpl,and__kcrctab_gpl_futurecontain checksums for all (GPL, or
future-GPL) exported functions of the module.__versionsincludes the checksums forallref-
erences used by the module from external sources.

The above sections are not created unless the version control feature was enabled
when the kernel was configured.

Section 7.5 deals in more detail with how version information is generated and used.
❑ __paramstores information on the parameters accepted by a module.
❑ __ex_tableis used to define new entries for the exception table of the kernel in case the module
code needs this mechanism.
❑ .modinfostores the names of all other modules that must reside in the kernel before a module
can be loaded — in other words, the names of all modules that the particular module
depends on.
In addition, each module can hold specific information that can be queried using themodinfo
userspace tool, particularly the name of the author, a description of the module, license informa-
tion, and a list of parameters.
❑ .exit.textcontains code (and possibly data) required when the module is removed from the
kernel. This information is not kept in the normal text segment so that the kernel need not load it
into memory if the option for removing modules was not enabled in the kernel configuration.
❑ The initialization functions (and data) are stored in.init.text. They are held in a separate
section because they are no longer needed after completion of initialization and can therefore
be removed from memory.
❑ .gnu.linkonce.this_moduleprovides an instance ofstruct module, which stores the name of
the module (name) and pointers to the initialization and clean-up functions (initandcleanup)
in the binary file. By referring to this section, the kernel recognizes whether a specific binary file
is a module or not. If it is missing, file loading is rejected.

(^11) readelf -S module.kolists all the sections in a module object.

Free download pdf