Linux Kernel module programming

Linux Kernel module programming-general Linux technology-Linux programming and kernel information. The following is a detailed description. The Linux kernel driver module programming guide was originally written by Ori Pomerantz for the kernel version 2.2. Later, Ori handed over the document maintenance task to Peter Jay Salzman, peter completed the compilation of the 2.4 kernel version document. After all, the Linux kernel driver module is a fast-updated content. At present, Peter cannot spare enough time to write the 2.6 kernel version document. At present, this 2.6 kernel version document is completed by Michael Burian, a partner.

Version and note
The Linux kernel module is constantly updated and improved. There is always a debate on whether the Linux kernel is retained or a historical version on the LKMPG. Michael and I finally decided to create a new Documentation Branch for each new stable version of the kernel. That is to say, LKMPG 2.4.x focuses on the 2.4 kernel, while LKMPG 2.6.x focuses on the 2.6 kernel. We will not provide support for earlier versions of the kernel in one document. Readers interested in this article should look for documentation branches of relevant versions.

Most of the source code and discussions in this document should be applicable to other platforms, but I cannot provide any guarantee. One of the exceptions is Chapter 12. The source code and discussion in the Chapter of Interrupt Processing is only applicable to the x86 platform.

Thanks
We would like to thank the following persons for their valuable comments on this document. They are: Ignacio Martin, David Porter, Daniele Paolo, Scarpazza, and Dimo Velev.
Translator's note
I am a translator named Tian Jing. I am currently a communication college student at Beijing University of Posts and Telecommunications. I have been a fan of Linux since I was in high school and have been following this path. I like the freedom that Linux brings to me. No one desires freedom.

When I was writing the kernel module, I first read the book about using the kernel version 2.0 by Orelly press, but as I expected, many examples in this book cannot be used due to kernel code changes. This makes me very worried about the mystery of the kernel module. I found this document in Linux documentation on the Image site ldp.linuxforum.net in Shanghai.

Encouraged by the original author Ori, based on the last LKMPG 2.4, the content was slightly changed and expanded. It should be the latest version. The translation method has changed. You can use the docbook format recognized by LDP to translate it into the html document in the attachment through docbook2html. Some of the titles in docbook are not translated, and may damage the original tag, leading to incorrect html display, but rarely. Modified many typos in 2.4.
The process of learning and sharing is the ultimate goal of my translation.


Chapter 1. Introduction
Table of Contents
What is a kernel module?
How is the kernel module transferred to the kernel?
What is a kernel module?
Now, do you want to write the kernel module. You should understand the C language and write some user programs, so now you will see some real things. Here, you will see how a brutal pointer destroys your file system. A kernel crash means restarting.

What is a kernel module? The kernel module is some code that allows the operating system kernel to load and execute as needed, which also means that it can be uninstalled without the need of the operating system. They extend the features of the operating system kernel, but do not need to restart the system. For example, a kernel module is a device-driven program module that allows the operating system to correctly identify and use hardware devices installed on the system. If there is no kernel module, we have to re-compile the kernel image of a Single Kernel Operating System to add new features. This also means a bloated kernel.
How is the kernel module transferred to the kernel?
You can run the lsmod command to check which kernel modules have been loaded by the kernel. This command reads the content of the/proc/modules file to obtain the required information.

How are these kernel modules transferred to the kernel? When the extended functions required by the operating system kernel are not stored, the kernel module management daemon kmod [1] executes modprobe to load the kernel module. Two types of parameters are passed to modprobe:


The name of a kernel module is like softdog or ppp.

The common identifier is char-major-10-30.

When a common identifier is passed to modprobe, modprobe first searches for the string in the file/etc/modules. conf. If it finds a line of alias like:

Alias char-major-10-30 softdog

It understands that the common identifier is pointing to the kernel module softdog. o.

Then, modprobe traverses the file/lib/modules/version/modules. dep to determine whether other kernel modules need to be loaded before the module is loaded. This file is created by command depmod-a and stores the dependency between kernel modules. For example, msdos. o depends on the fat. o kernel module that has been loaded by the kernel. When the kernel module to be loaded needs to use the symbolic links provided by other modules (most of which are variables or functions), the kernel modules that provide these symbolic links will be depended on by this module.

Finally, modprobe calls insmod to first load the dependent module and then load the module required by the kernel. Modprobe points insmod to the/lib/modules/version/[2] Directory, which is the default standard directory for storing kernel modules. Insmod processes the storage location of the kernel module, so modprobe should clearly know the location of the default standard kernel module. Therefore, when you want to load an inner-core module, You can execute:

Insmod/lib/modules/2.5.1/kernel/fs/fat. o
Insmod/lib/modules/2.5.1/kernel/fs/msdos. o

Or just execute "modprobe-a msdos ".

In Linux, modprobe, insmod and depmod are provided in a toolkit named modutils or mod-utils.

Before finishing this chapter, let's take a look at the/etc/modules. conf file:

# This file is automatically generated by update-modules
Path [misc] =/lib/modules/2.4 .? /Local
Keep
Path [net] = ~ P/mymodules
Options mydriver irq = 10
Alias eth0 eepro

Use '#' to comment on the starting behavior. Blank rows are ignored.

The line starting with path [misc] tells modprobe to use/lib/modules/2.4 .? /Local replaces the path of the misc kernel module. As you can see, the metacharacters of the command interpreter shell can also be used.

The line starting with path [net] tells modprobe to be in the directory ~ P/mymodules search for kernel modules in the network. However, the "keep" command used before the path [net] Command tells modprobe to only add the path to the standard search path, rather than replacing it as before misc.

Load eepro. o with the exercise modprobe starting from alias when the kmod uses the universal identifier 'eth0' to load the corresponding kernel module.

You will not find alias lines like "alias block-major-2 floppy" in the file/etc/modules. conf because modprobe already knows the driver modules of standard devices installed on most systems.

Now you know how the kernel module is transferred in. When you want to write your own kernel modules dependent on other modules, there is still some content not provided. This relatively advanced issue will be introduced in subsequent chapters when we have completed the previous study.

Before you start
Note the following before we introduce the source code. Differences between systems can lead to many difficulties. It is sometimes difficult to compile and load your first "hello world" module. But when you cross this hurdle, it will be much smoother in the future.

Kernel module and kernel version
Modules compiled for a specific version cannot be loaded by another version of the kernel if the CONFIG_MODVERSIONS option is enabled in the kernel. We will not discuss relevant content for the moment. Before entering the relevant content, the examples in this document may not work when this option is enabled. However, most distributions currently enable this option. So if you encounter a version-related error, it is best to re-compile a kernel to disable this option.

Problems caused by using X
It is strongly recommended that you enter sample code in the document in the console, compile and load the module, instead of under X.

Modules cannot output to the screen like printf (), but they can record information and warnings. This information can only be displayed on the screen when you are using the console. If you use an insmod module in xterm, the log information will only be recorded in your log file. In addition to viewing log files, you cannot obtain output information. If you want to obtain the log information in time, we recommend that you do all the work in the console.

Compilation issues related to kernel versions
Linux distributions often provide some non-standard patches for the kernel, which may cause some problems.

A more common problem is that some Linux distributions provide incomplete header files. When compiling a module, you need a lot of kernel header files. One of Murphy's rules is that the missing header files are exactly what you need most.

I strongly recommend that you download the source code package from the Linux image site, compile the new kernel, and start the system with the new kernel to avoid the above problems. See "Linux Kernel HOWTO" for details.

The irony is that this will also lead to some problems. Gcc tends to find source code files in the default kernel source file path (usually/usr/src. This can be switched through the-I option of gcc.

Notes
[1] In earlier linux versions, it was a daemon named kerneld.

[2] If you are modifying the kernel, to avoid overwriting the module you are currently working on, you should try using the EXTRAVERSION variable in the kernel Makefile to create a unique Module Directory.