06-B.4: Kernel Modules

Last updated
Save as PDF

Page ID: 32707

$ \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } $ $ \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} $$\newcommand{\id}{\mathrm{id}}$ $ \newcommand{\Span}{\mathrm{span}}$ $ \newcommand{\kernel}{\mathrm{null}\,}$ $ \newcommand{\range}{\mathrm{range}\,}$ $ \newcommand{\RealPart}{\mathrm{Re}}$ $ \newcommand{\ImaginaryPart}{\mathrm{Im}}$ $ \newcommand{\Argument}{\mathrm{Arg}}$ $ \newcommand{\norm}[1]{\| #1 \|}$ $ \newcommand{\inner}[2]{\langle #1, #2 \rangle}$ $ \newcommand{\Span}{\mathrm{span}}$ $\newcommand{\id}{\mathrm{id}}$ $ \newcommand{\Span}{\mathrm{span}}$ $ \newcommand{\kernel}{\mathrm{null}\,}$ $ \newcommand{\range}{\mathrm{range}\,}$ $ \newcommand{\RealPart}{\mathrm{Re}}$ $ \newcommand{\ImaginaryPart}{\mathrm{Im}}$ $ \newcommand{\Argument}{\mathrm{Arg}}$ $ \newcommand{\norm}[1]{\| #1 \|}$ $ \newcommand{\inner}[2]{\langle #1, #2 \rangle}$ $ \newcommand{\Span}{\mathrm{span}}$$\newcommand{\AA}{\unicode[.8,0]{x212B}}$

EXAM OBJECTIVES COVERED
1.2 Given a scenario, install, configure, and monitor kernel modules.
1.3 Given a scenario, configure and verify network connection parameters.
4.1 Given a scenario, analyze system properties and remediate accordingly.

Linux Kernel Modules

Kernel modules are pieces of code that can be loaded and unloaded into the kernel upon demand. They extend the functionality of the kernel without the need to reboot the system. A module can be configured as built-in or loadable. To dynamically load or remove a module, it has to be configured as a loadable module in the kernel configuration.

There are several advantages that come with using kernel modules:

The kernel does not have to rebuild your kernel as often. This saves time and prevents the possibility of introducing an error in rebuilding and reinstalling the base kernel. Once you have a working base kernel, it is good to leave it untouched as long as possible.
It is easier to diagnose system problems. A bug in a device driver which is bound into the kernel can stop the system from booting at all. It can also be really hard to tell which part of the base kernel caused the trouble. If the same device driver is a module, though, the base kernel is up and running before the device driver even gets loaded. If the system dies after the base kernel is up and running, it's an easy matter to track the problem down to the trouble-making device driver and just not load that device driver until the problem is fixed.
Using modules can save memory, because they are loaded only when the system is actually using them. All parts of the base kernel stay loaded, in real storage, not just virtual storage.
Modules are much faster to maintain and debug. What would require a full reboot to do with a filesystem driver built into the kernel can be done with a few quick commands using modules. It is possible to try out different parameters or even change the code repeatedly in rapid succession, without waiting for a boot.
Modules are not slower, by the way, than base kernel modules. Calling either one is simply a branch to the memory location where it resides.

Module Location

The code necessary to create a new kernel with new module included, or old modules removed is usually: /lib/modules/$(uname -r)/kernel although on some distributions the code is found in /usr/lib/modules/$(uname -r)/kernel. The /usr/lib and /lib directory is where Linux stores object libraries and shared libraries that are necessary to run certain commands, including kernel code.

These directories are only necessary if you wish to rebuild your kernel with new modules included, or old modules removed. It would be best to seek out assistance from a source knowledgeable with the specific distribution you are working with.

Kernel Modules Subdirectories:

Directory	Description
arch	The arch subdirectory contains all of the architecture specific kernel code. It has further subdirectories, one per supported architecture, for example i386 and alpha.
include Although man distributions place the include files in the /usr/src/$(uname -r)	The include subdirectory contains most of the include files needed to build the kernel code. It too has further subdirectories including one for every architecture supported. The include/asm subdirectory is a soft link to the real include directory needed for this architecture, for example include/asm-i386. To change architectures you need to edit the kernel makefile and rerun the Linux kernel configuration program.
init	This directory contains the initialization code for the kernel and it is a very good place to start looking at how the kernel works.
mm	This directory contains all of the memory management code. The architecture specific memory management code lives down in arch/*/mm/, for example arch/i386/mm/fault.c.
drivers	All of the system's device drivers live in this directory. They are further sub-divided into classes of device driver, for example block.
ipc	This directory contains the kernels inter-process communications code.
modules	This is simply a directory used to hold built modules.
fs	All of the file system code. This is further sub-divided into directories, one per supported file system, for example vfat and ext2.
kernel	The main kernel code. Again, the architecture specific kernel code is in arch/*/kernel.
net	The kernel's networking code.
lib	This directory contains the kernel's library code. The architecture specific library code can be found in arch/*/lib/.
scripts	This directory contains the scripts (for example awk and tk scripts) that are used when the kernel is configured.

Adapted from:
"2. Introduction to Linux Loadable Kernel Modules" by Unlisted, The Linux Documentation Project is licensed under CC BY-SA 3.0