SMART210 Learning record-------Linux kernel modules

Linux driver engineers need to have a solid grasp of the Linux kernel's compilation method to build an embedded system that can run
Linux operating system image. When compiling the kernel of LDD6410, you need to configure the kernel, you can use the following command
One:
#make Config (the most traditional text-based configuration interface, not recommended)
#make menuconfig (Text menu-based configuration Interface)
#make Xconfig (requires QT to be installed)
#make Gconfig (requires GTK + to be installed)
Make config, make menuconfig, make xconfig and make gconfig used in configuring the Linux 2.6 kernel
The most recommended of these 4 ways is make menuconfig, which does not depend on QT or GTK +, and is very intuitive to
LDD6410 's Linux 2.6.28 kernel runs make Menuconfig

The kernel configuration contains quite a few items, and the Arch/arm/configs/ldd6410lcd_defconfig file contains the LDD6410
Default configuration, so you can configure the kernel for the LDD6410 board only if you need to run make ldd6410lcd_defconfig.
The methods for compiling the kernel and modules are:
Make Zimage
Make modules
After executing the above command, the uncompressed kernel image vmlinux and kernel symbol tables are obtained under the root directory of the source code.
System.map, the arch/arm/boot/directory will be compressed kernel image zimage, in the corresponding directory of the kernel is selected
Kernel modules.

The Linux 2.6 kernel configuration system consists of the following 3 parts.
! Makefile: Makefile, which is distributed in the source code of the Linux kernel, defines the compilation rules for the Linux kernel.
! Configuration file (Kconfig): Provides the user with the ability to configure the selection.
! Configuration tools: Includes configuration command interpreter (explanation of configuration commands used in configuration scripts) and configuring users
Interface (provides a character-based interface and a graphical interface). These configuration tools use scripting languages, such as TCL/TK,
Perl and other writing.

Kconfig Makfile
Adding a program to the Linux kernel requires the following 3 tasks to be completed.
! Copy the written source code into the appropriate directory for the Linux kernel source.
! Add compile configuration options for the Xinyuan code corresponding project in the directory's Kconfig file.
! Add a compilation entry to the Xinyuan code in the directory's Makefile file.

A Linux kernel module consists mainly of the following parts.
(1) Module load function (typically required).
When a kernel module is loaded via the Insmod or Modprobe command, the module's load function is automatically executed by the kernel, completing
The related initialization of this module.
(2) module unload function (usually required).
When a module is unloaded via the Rmmod command, the Unload function of the module is automatically executed by the kernel, complete with the module unload function
The opposite function.
(3) Module License Statement (required).
The license (LICENSE) statement describes the license permissions of the kernel module, and if LICENSE is not declared, the module is loaded,
will receive a warning that the kernel is contaminated (kernel tainted).
In the Linux 2.6 kernel, acceptable license include "GPL", "GPL v2", "GPL and additional rights",
"Dual BSD/GPL", "Dual MPL/GPL" and "proprietary".
In most cases, the kernel module should follow the GPL-compatible license. The most common Linux 2.6 kernel modules are
The Module_license ("Dual BSD/GPL") statement declares that the module uses BSD/GPL dual LICENSE.
(4) module parameters (optional).
A module parameter is a value that can be passed to a module when it is loaded, which itself corresponds to a global variable inside the module.
(5) module export symbol (optional).
The kernel module can export symbols (symbol, which corresponds to a function or variable) so that other modules can use the variable in this module
Volume or function.
(6) Information statements such as module authors (optional).

**********************************************************************************************
Module load function

The Linux kernel module load function is typically declared as _ _init, and a typical module load function is in the form of a code listing
static int __init initialization_function (void)
{
...
}
Module_init (initialization_function);

The module load function must be specified in the form "Module_init (function name)". It returns an integer value that, if initialized successfully,
should return 0. In the case of initialization failure, an error encoding should be returned. In the Linux kernel, the error code is a negative value,
<linux/errno.h>, which contains symbolic values such as-enodev,-enomem, and so on. Always return the corresponding error code is
Very good habits, because only then, the user program can use perror and other methods to convert them into meaningful errors
The information string.
In the Linux 2.6 kernel, you can use Request_module (const char *FMT, ...) The function loads the kernel module, drives the
The sender can call the
Request_module (module_name);
Or
Request_module ("char-major-%d-%d", Major (Dev), MINOR (Dev));
This flexible way to load other kernel modules.
In Linux, all functions identified as _ _init are placed in the. Init.text section during connection, in addition, all
The _ _init function in the section. Initcall.init also holds a copy of the function pointers that the kernel passes through when initialized
Call these _ _init functions and release the Init section (including. Init.text,. Initcall.init, and so on) after initialization is complete.

**********************************************************************************************

**********************************************************************************************
Module Unload function
Linux kernel module Loading functions are typically declared with _ _exit, typically in the form of a module unload function such as a code listing

static void __exit cleanup_function (void)
{
...
}
Module_exit (cleanup_function);

The

Module unload function executes when the module is unloaded, does not return any values, and must be specified as a "module_exit (function name)" Shape
.
Typically, the module unload function accomplishes the opposite function as the module load function, as shown below.
! If the module loader function is registered with XXX, the module unload function should unregister xxx.
! If the module load function dynamically requests memory, the module unload function should free the memory.
! If the module load function requests the use of hardware resources (interrupts, DMA channels, I/O ports, and I/O memory, etc.), the module unload function should release these hardware resources.
! If the module loading function turns on the hardware, the Unload function is generally closed. As with the
and _ _init, _ _exit can also enable the corresponding function to automatically reclaim memory after it has finished running. In fact, _ _init and _ _exit
are macros, which are defined as:
#define _ _init _ _attribute_ _ (_ _section_ _ (". Init.text"))
and
#ifdef M Odule
#define _ _exit _ _attribute_ _ ((_ _section_ _ (". Exit.text"))
#else
#define _ _exit _ _attribute_used_ _attribute_ _ (_ _section_ _ (". Exit.text")))
#endif
Data can also be defined as _ _initdata and _ _exitdata, respectively:
#define _ _in Itdata _ _attribute_ _ ((_ _section_ _ (". Init.data")))
and
#define _ _exitdata _ _attribute_ _ (_ _section_ _ (". ex It.data "))

******************************************************************************************** **

Module parameters
We can define a parameter for the module with "Module_param (parameter name, parameter type, parameter read/write permission)", for example
The column code defines 1 integer parameters and 1 character pointer parameters:

static char* PR = "Hello World";
static int num = 5;
Module_param (PR, Charp, S_irugo);
Module_param (num, int, s_irugo);

When loading a kernel module, the user can pass parameters to the module in the form "Insmode (or modprobe) module name parameter
Number = parameter Value ", if not passed, the parameter will use the default value defined within the module.
Parameter types can be byte, short, ushort, int, uint, long, ulong, charp (character pointer), BOOL, or Invbool
(Boolean inverse), when the module is compiled, the type declared in Module_param is compared with the type defined by the variable, judging
are consistent.
After the module is loaded, a directory named after the module name will appear in the/sys/module/directory. When "parameter read/write permission" is 0
Indicates that this parameter does not exist for the corresponding file node under the Sysfs file system, if the module has "parameter read/write permission" not 0
command-line arguments, the parameters directory will also appear under the directory for this module, containing a series of file nodes named after the parameter name.
The permission values for these files are the parameter read/write permission for incoming Module_param (), and the content of the file is the value of the parameter.

In addition, the module can have an array of parameters, in the form "Module_param_array (array name, array type, number leader, parameter
Read/write permission) ". From the 2.6.0~2.6.10 version, you need to assign the number leader variable name to "number leader", starting with the 2.6.10 version, you need to set the array
Long variable pointer to "number leader", when you do not need to save the actual input array element number, you can set "number leader" is null.
When you run the Insmod or modprobe command, you should separate the input array elements with commas.

**********************************************************************************************
Export symbols

Linux 2.6 's "/proc/kallsyms" file corresponds to the kernel symbol table, which records the symbol and the memory address where the symbol resides.
The module can use the following macros to export symbols to the kernel symbol table:
Export_symbol (symbol name);
EXPORT_SYMBOL_GPL (symbol name);
The exported symbols will be used by other modules and can be declared before use.

**********************************************************************************************

Module declaration and description
In the Linux kernel module, we can use Module_author, module_description,
Module_version, Module_device_table, Module_alias, respectively, declare the author of the module, the description
versions, device tables, and aliases, such as:
Module_author (AUTHOR);
Module_description (DESCRIPTION);
Module_version (version_string);
Module_device_table (Table_info);
Module_alias (Alternate_name);
Http://weibo.com/21cnbao

**********************************************************************************************
Usage count of the module

The introduction and use of Try_module_get () and Module_put () is closely related to the device model under the Linux 2.6 kernel. Linux
The 2.6 kernel defines a struct module *owner domain for different types of devices to point to the module that manages this device. When you start
When using a device, the kernel uses Try_module_get (Dev->owner) to increase the use of the owner module that manages this device.
When this device is no longer used, the kernel uses module_put (Dev->owner) to reduce the number of the owner module that manages this device.
Use count. This way, the module that manages this device cannot be uninstalled when the device is in use. Only when the device is no longer in use,
The module is not allowed to be uninstalled.
Under the Linux 2.6 kernel, it is very rare for device driver engineers to call Try_module_get () and
Module_put (), because at this point the developer writes a driver that is typically the owner module that supports a specific device, the owner
The module's count management is implemented by a lower-level code in the kernel, such as a bus driver or a core module shared by such devices, thus simplifying
Development of device drivers.

For details, see LINUCX device driver development

SMART210 Learning record-------Linux kernel modules