Linux device model (1)

As computer peripherals become more and more abundant, device management has become an important task of modern operating systems, which is the same for Linux. Each time a new version of the Linux kernel is released, a number of device drivers will enter the kernel. In the Linux kernel, the amount of driver code occupies a considerable proportion. It is a statistical graph of the Linux kernel code volume that I found on the network. The corresponding kernel version is 2.6.29.

We can clearly see that the proportion of drivers in the Linux kernel is already very high.

The Linux 2.6 kernel initially proposed a device model to manage all the devices to cope with power management needs. Physically, there is a hierarchical relationship between peripherals. For example, if a USB flash drive is inserted into a notebook, the USB flash drive is actually connected to a USB hub, USB hub is connected to USB 2.0 host controller (EHCI), and EHCI is a device mounted on PCI bus. Here is a hierarchical relationship: PCI-> EHCI-> USB hub-> USB disk. If the operating system is to enter sleep state, it must first notify all peripherals to enter sleep mode layer by layer before the entire system can sleep. Therefore, a tree structure is required to organize all peripherals. This is the purpose of establishing a Linux device model.

Of course, the Linux device model brings us far more benefits than that. Now that a tree structure has been established for all devices and drivers in the organization, you can traverse all devices through this tree to establish the connection between devices and drivers, devices can also be categorized based on different types, so that you can "see" this thriving tree more clearly. In addition, the Linux Driver Model abstracts some common operations of many devices, greatly reducing the possibility of duplicate operations. At the same time, the Linux device model provides some auxiliary mechanisms, such as reference counting, allowing developers to develop drivers securely and efficiently. After achieving the above benefits, we also got a very convenient by-product, namely sysfs-a virtual file system. Sysfs provides users with a way to access the kernel device from the user space. Its Path in Linux is/sys. This directory is not a real file system stored on the hard disk. It is created only after the system is started.

The following command can be used to display the approximate structure of sysfs:

Tree/sys

I will not post this command because it contains a large amount of information. If you are interested, you can check it out or experiment it yourself.

Let's take a look at the first-level directory structure:

/Sys
| -- Block
| -- Bus
| -- Class
| -- Dev
| -- Devices
| -- Firmware
| -- FS
| -- Kernel
| -- Module
'-- Power

There are 10 sub-directories, but they do not mean that these 10 directories represent 10 completely different device types, in fact, these directories only provide us with different perspectives on how to look at the entire device model. In fact, it is possible to find the same device from different directories. So where is the real device information? Check the directory name and you will be able to guess, right, that is, the devices sub-directory. All Linux devices can be found in this directory. This is a hodgedge, but we have no way to do it despite being dirty. Here we take the USB flash drive as an example. After inserting the USB flash drive, how can we find this USB flash drive in the devices directory? It's really hard to do. But if you know the name of the device file in the system of the USB flash drive (which is assumed to be SDB), you can start with the block directory.

Through the block directory, we can easily find this USB flash drive device. The Symbolic Link Device points to the location under the devices directory.

Here, we will summarize the functions of each subdirectory in the/sys directory. The block directory organizes devices from the perspective of Block devices. The bus directory organizes devices from the perspective of the system bus, such as PCI bus or USB bus; the class directory increases the viewing angle to the category level, such as PCI devices or USB devices. The dev directory perspective is the device node. The devices directory is mentioned earlier, here is the base camp for all devices; the firmware directory contains some low-level subsystems, such as ACPI and EFI; the FS directory shows all the file systems supported by the system; the kernel directory contains Kernel configuration options. The modules directory contains information about all kernel modules. The kernel module actually corresponds to the device, you can use this directory to find the devices or vice versa. The power directory stores the system power management data, and you can use it to query the current power status, you can even directly "command" the system to enter sleep and other power-saving modes.

Sysfs is a bridge between users and kernel device models. Through this bridge, we can read information from the kernel or write information to the kernel.

In Linux, you can also find some graphical tools to query device information. For example, Hal-based Device Manager in GNOME:

Or kinfocenter based on solid in KDE:

These graphical tools provide a more intuitive way to access devices, but the information they provide is not comprehensive enough, and there is no function to write data to the kernel device.

For a specific type of device, there are some dedicated tools available in Linux. For example, PCI utils for PCI devices, usbutils for USB devices, and lsscsi for SCSI devices. For Linux developers, it is sometimes easier to use these dedicated tools.

If you want to write a program to access sysfs, you can operate the files in the/sys directory like reading and writing common files, or use libsysfs. However, libsysfs is not recommended in the Linux Kernel community because the API is not updated fast enough to keep up with kernel changes. Libsysfs has gradually deviated from its initial goal. This lib seems to cause more problems than it solves. Of course, if you only want to access the device, sysfs is rarely directly operated. The details are too low-level. In most cases, you can use the more convenient devicekit or libudev.

 

To sum up, This article briefly introduces the basic concepts of the Linux Device Model and the Virtual File System sysfs. In the next chapter, we will continue to discuss some details about the device model in the kernel space.