Linux kernel design and implementation 17th Chapter

1. Device Type

Linux is comprised of 3 types of devices, namely:

Device type	Represents a Device	Characteristics	Access mode
Block devices	Hard disk, CD	Random access to content in the device	The device is usually mounted as a file system and then accessed
Character device	Keyboards, printers	Only sequential access (one character or one byte)	Normally not mounted, directly interacting with the device
Network equipment	Card	Broke the Unix "everything is file" design principle	Access via Socket API

In addition to the above 3 typical devices, there are "pseudo-devices", which are virtual devices that provide only access to the kernel, and no physical devices are associated with them.

2. kernel modules

The Linux kernel is modular, the kernel module can be loaded on demand, so that the kernel boot without loading all the modules, that is, reduce the size of the kernel, but also improve efficiency.

It is a good way to add functionality or interfaces to the kernel by writing kernel modules, without recompiling the kernel or debugging and deleting it.

2.1 Kernel Module Example

2.1.1. kernel modules with no parameters

2.1.2. kernel modules with parameters

It is not difficult to construct kernel modules with parameters, and the kernel has provided a simple framework for declaring parameters.

1. Module_param (name, type, perm): Define a module parameter

+ Parameter name:: Is both the user-visible parameter name and the variable name that holds the module parameter in the module

+ parameter type:: Parameter types (byte, short, int, uint, long, ulong, CHARP, bool ...) The byte type is stored in the char variable, and the bool type is stored in the INT variable

+ parameter perm:: Specify the file permissions of the module in the Sysfs file system (described later in the SYSFS section)

2. module_param_named (name, variable, type, perm): Defines a module parameter, and the parameter is not the same as the external name

+ Parameter name:: User-Visible parameter name

+ parameter variable:: variable name of module parameter stored in module

+ Parameter type and perm:: Type and perm in the same module_param

3. Module_param_string (name, string, Len, perm): Copies the string to the specified character array

+ Parameter name:: User-Visible parameter name

+ parameter string:: Variable name for module parameters stored in module

+ Parameter len:: string parameter's buffer length

+ parameter perm:: Perm in the same module_param

4. Module_param_array (name, type, Nump, perm): Defines the module parameters of the array type

+ parameter name:: Name in the same module_param

+ Parameter type:: Type in the same module_param

+ parameter nump:: integer pointer, storing the length of the array

+ parameter perm:: Perm in the same module_param

5. Module_param_array_named (name, array, type, Nump, perm): Defines the module parameter of the array type, and the array parameter is not the same as the name of the internal and external

+ Parameter name:: Array Parameters external names

+ parameter array:: Array parameter internal name

+ parameter type,nump,perm:: Type,nump,perm in the same module_param_array

6. Parameter Description macro

You can add some descriptive information to the parameters of the kernel module by Module_parm_desc ().

These descriptive information can be viewed through the modinfo command after the kernel module has been compiled.

2.2 location of kernel modules

2.2.1. Outside the kernel code

2.2.2. In the kernel code

The code of the kernel module can also be placed directly into the kernel code tree.

The kernel module that completes this drive can be added to the driver location in the kernel code tree when the driver is written.

After that, the new driver is compiled as a kernel module when the kernel is compiled.

2.3 kernel module related Operations

2.3.1. Module installation

Make Modules_install <--install modules that are compiled with the kernel into the appropriate directory

2.3.2. Module dependencies

Commands for automatic production module dependencies in Linux:

Depmod <--generates kernel dependency information

Depmod-a <--only generates dependency information for new modules (faster)

2.3.3. Loading of modules

Kernel module experiments have been used:

Insmod Module.ko

<--recommends using the following command to automatically load dependent modules

modprobe module [module parameters]

2.3.4. Unloading of the module

Kernel module experiments have been used:

Rmmod Module.ko

<--recommends using the following command to automatically unload dependent modules

MODPROBE-R Module

2.3.5. module Export Symbol table

Once the kernel module is loaded, it loads into the kernel dynamically and needs to be exported in order for the other kernel modules to use their functionality.

Methods for exporting functions in kernel modules:

Export_symbol (function name) <--after the functions you want to export

EXPORT_SYMBOL_GPL (function name) <--and Export_symbol, the difference is that only the modules marked as GPL protocol are visible

3. Kernel Objects

The 2.6 kernel adds a compelling new feature-the unified device model.

The original motivation for the unified device model was to enable intelligent power management, and the Linux kernel needed to establish a tree structure that represented the topological relationships of all the devices in the system in order to achieve intelligent power management.

This can be turned off from the node of the tree when power is turned off.

Once the unified device model is implemented, the following benefits are provided to the kernel:

1. Code duplication minimization (Unified processing of more things)

2. You can enumerate all the devices in the system, observe their status, and view their connected bus

3. All the devices in the system can be fully and effectively displayed in tree form-including all bus and internal connections

4. The device can be connected to its corresponding driver and vice versa

5. The device can be categorized by type without understanding the topology of the physical device

6. You can loop through the leaves of the plant tree to its root to ensure that the device power is turned off in the correct order

3.1 Kobject Introduction

The core part of the unified device model is kobject, which gives an overview of how the physical devices can be organized in a tree structure by introducing the kobject structure below.

3.1.1. kobject

Kobject itself does not represent what the actual content, is generally embedded in other data structures to play a role. After embedding the Kobject, there is a tree structure between the cdev devices, and there is a hierarchical relationship between the Cdev device and other devices.

3.1.2. Ktype

Ktype is to describe the universal properties of a family of kobject, that is, to define the properties of the kobject of this family uniformly, and to avoid defining each kobject separately.

3.1.3. Kset

Kset is a collection of Kobject objects that can be placed in a kset for all relevant kobject, such as all "block devices" that can be placed in a kset that represents a block device.

3.1.4. The relationship between Kobject,ktype and Kset

Of these 3 concepts, Kobject is the most basic. Kset and Ktype are designed to classify kobject in order to centralize processing of common processing, thus reducing the amount of code and also increasing maintainability.

Here Kset and Ktype are to classify the kobject, why is there 2 classification?

From the code of the whole kernel, in fact, the number of kset is more than the number of Ktype, the same ktype Kobject can be located in different kset.

A not very appropriate analogy, if the kobject compared to a person, kset equivalent to a country, Ktype is the equivalent of race (such as yellow, white, etc.).

There are only a few types of races, but there are many countries, and the aim of the race is to describe the common attributes of a group of people, and the country's purpose is to manage a group of people.

Similarly, Ktype focuses on the description, and Kset focuses on management.

3.1.5. Kref

Kref records the number of times the kobject is referenced, and when the reference count drops to 0, the release function releases the associated resource.

4. Sysfs

Sysfs is an in-memory virtual file system that provides a view of the Kobject object hierarchy.

You can use the following command to view the structure of the/sys

Tree/sys # Show all directories and files

Or

Tree-l 1/sys # Show only one level of directory

Linux kernel design and implementation 17th Chapter