[Transfer] Introduction to Linux sysfs device driver management

First: Introduction to sysfs device driver management

sysfs is a non-persistent virtual file system that provides a global view of the system and displays the hierarchy (topology) of kernel objects through their kobiect. Each kobiect appears as a file within a directory and a directory represents the kernel variables exported by the associated kobject. These files are called properties and can be read or written. If any registered kobiect creates a directory in sysfs, where the directory is created depends on the kobiect's parent (which is also a kobiect). These directories are naturally created as subdirectories of the kobject's parent. This exposes the internal object hierarchy to user space. The top-level directory in sysfs represents the common ancestor of the object hierarchy, the subsystem to which the object belongs.

For each block device on the system, a block contains a directory containing subdirectories for partitions on the device. bus contains the buses registered on the system. dev contains registered device nodes in raw fashion (no hierarchy), each node is a symbolic link to a real device in the /sys/devices directory. devices gives a topological view of the devices in the system. firmware Displays system-dependent low-level subsystem trees such as ACPI, EFI, 0F (DT). fs lists the actual filesystems in use on the system. kernel holds kernel configuration options and state information. module is a list of loaded modules.

• ●kernel_ kobj : corresponds to /sys/kernel.

• ● power_ kobj: corresponding to /sys/power.

• ●firmware_ kobj: corresponding to /sys/firmware, exported in the drivers/baselirmware.c source file.

• ●hvpervisor_ kobj: corresponding to /sys/hypervisor, exported in drivers/base hypervisor.c.

• ● fs_ kobj : corresponding to /sys/fs, exported in fs/namespace.c file.

However, class/, dev/, devices/ are created during boot by the devices_init function in drivers_base/core.c within the kernel source, block/ is created in block/genhd.c, bus/ is created in drivers/base /bus.c is created as kset.

When a kobject is added to sysfs (using kobject_ _add), its location depends on the kobject's parent. If its parent pointer is set, it will be added as a subrecord within the parent record. If the parent pointer is NULL, add it as a sub-record within kset->kobj. If neither its parent nor kset fields are set, it maps to the root directory (/sys) within sysfs.

Second: sysfs device driver management related registration interface

Everything in the Linux system is a file.

Where is the device file? It is recorded in /dev, and it is also recorded in /sys. What is the difference between them directly?

• ●/dev directory: The files under this directory are real device files, which are files created by the application layer through mknod. Usually, the system is created by udev at runtime. We usually use open, write, ioctl and other functions to operate the device, usually to operate the files under the /dev directory, which will indirectly call the underlying driver function.

• ●/sys directory: This is exported by the kernel at runtime, the purpose is to display the hierarchical relationship of devices, drivers and buses through the file system. This is also the focus of this chapter. Then first take a look at how the sysfs file system is built through the following figure. The left side of the figure is the initialization process, and the right side is the directory structure corresponding to the sysfs file system.

It can be seen that sysfs is not simply related to device drivers, but also includes many managements such as kernel modules, kernel parameters, and power supplies. Of course, these can also be regarded as device or driver modules from a certain angle. However, they are not the focus of our analysis. What we need to analyze is mainly related to device drivers. This picture just gives us a spectrum in our minds, knowing what it has and where it is initialized.

Here we are not going to analyze the management of device drivers by sysfs directly through the sysfs file directory hierarchy. We analyze the hierarchical structure of the sysfs file directory from the registration addition and process of devices, drivers, and buses. Their main registration functions are device_register, driver_register, bus_register, and the inevitable class_register.

Third: The main function of device_register

Through the device_register call stack in the above figure, you can see that the main initialization of the device is to create a directory with its own name (such as xxx-device) under /sys/devices/***/, and then create its own property file interface in it . At the same time, it will create a subsystem link, pointing to the bus or class, indicating the type it belongs to. Hanging under the bus means that it is controlled by a certain bus. If it is hung under the class, this is only a matter of perspective, and its essence is also It means that it has some common attributes, and even the consistency in management operation attributes. Then there is no need to create duplicate things under /sys/bus or /sys/class, and directly create a link to point to device, which means that from their directory, you can see which devices are controlled by bus or class. After device_register, the created directory and link relationship are as follows:

The management method of files and directories here is essentially the management idea of ​​data structure. The directory can be regarded as a structure, the file is a member of the data structure, and the link file is a data pointer. The above figure is actually the initialization of these data structures, and then the establishment of the relationship between the structures.

Fourth: What did driver_register do?

So by looking at what driver_register has done?

The driver_register call relationship is shown in the figure above, and it can be seen that it does much less than device registration. It mainly creates a directory with its own name under the /sys/bus/xxx-bus/drivers directory, and then initializes the driver property file in it. At the same time, a link is created to point to the module, indicating which kernel module provides the function of the driver. Similarly, the module also points back to the driver, indicating what kind of driving capability it provides. Of course, only the driver module will have a link to the driver. After driver_register, the directory and link relationship formed are as follows:

Fifth: What did bus_register do?

As can be seen from the above figure, it mainly creates a bus directory commanded by its own name under the /sys/bus directory (the name here is xxx-bus for example), and then creates devices and drivers for its managed devices and drivers Register, and create the drivers_probe and drivers_autoprobe property files for the driver to provide triggers for users to detect. Of course, the creation of uevent event files is indispensable, and finally there are some unique attributes of the bus itself. After registering the bus, the directory structure will be generated as follows:

Finally, take a look at what class_register has done?

The behavior of class_register is relatively simple, just create a self-named directory under /sys/class, mainly to provide a link for device registration. The action of linking is done in device_register.

summary

Summary: Through the above images, I have a basic understanding of the device driver registration on the sysfs file system and the approximate logical relationship. If you use the tree command to view /sys, you will definitely find that the folders of PCI, USB and other devices under the /sys/devices directory are stacked one after another, which involves a specific internal management relationship between them, and will not be described here.

Reprint address: https://www.elecfans.com/emb/202210141905091.html