Turn Linux device model (1)

Wwang
Source: Http://www.cnblogs.com/wwang
This article uses the Creative Commons Attribution-Non-commercial use-the same way to share 2.5 Chinese mainland License Agreement license, welcome reprint, but without the consent of the author must retain this paragraph statement, and in the article page obvious location to give the original text connection.

With more and more peripheral peripherals, device management has become an important task for modern operating systems, which is the same for Linux. Every time a new version of the Linux kernel is released, it is accompanied by a batch of device drivers into the kernel. In the Linux kernel, the driver code volume occupies a significant proportion. is a graph of the amount of Linux kernel code i have searched on the web, and 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 was originally presented with a device model to manage all devices in order to cope with power management needs. In physics, there is a hierarchical relationship between peripherals, such as a USB stick into the notebook, in fact, this USB stick is connected to a USB hub, the USB hub is connected to the USB 2.0 Host Controller (EHCI), the final EHCI is a hung in the PCI The device on the bus. Here is a hierarchical relationship: Pci->ehci->usb hub->usb Disk. If the operating system goes into hibernation, the first step is to notify all peripherals to sleep mode, and then the entire system can hibernate. Therefore, a tree-like structure is needed to organize all the peripherals. This is the purpose of the initial establishment of the Linux device model.

Of course, the Linux device model brings us much more convenience. Now that you have built a tree structure of all the devices and drives, the user can traverse all the devices through the tree, establish the connection between the device and the driver, and classify the device according to the type, so that you can "see" the leafy tree more clearly. In addition, the Linux drive model abstracts some of the operations common to many devices, greatly reducing the possibility of duplicating wheels. At the same time, the Linux device model provides a number of ancillary mechanisms, such as reference counting, that enable developers to develop drivers safely and efficiently. Having achieved these benefits, we have also got a very handy byproduct, which is SYSFS----a virtual file system. SYSFS gives the user a way to access the kernel device from the user space, and its path in Linux is/sys. This directory is not a real file system stored on the hard disk and will only be built after the system is booted.

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

Tree/sys

The information of this command is very large, I will not post it out, if you are interested can look here, or do your own experiment.

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 subdirectories, but not that the 10 directories represent 10 different types of devices, and in fact these directories provide us with a different perspective on how to look at the entire device model. In fact, it is possible to find the same device from different catalogs. Where exactly does the real device information be placed? Look at the directory name should be able to guess, yes, is the Devices subdirectory, all Linux devices can be found in this directory. Here is a hodgepodge, although perfectly formed but we do not know. Here or a U disk as an example, after inserting a U disk, in the devices directory how to find this U disk? It's really hard to do. However, if you know the device file name of the USB flash drive in the system (for the moment, SDB is assumed), you can start with the block directory.

With the block directory, it's easy to find the USB stick device, where the symbolic link device is pointing to the devices directory.

Here, we summarize the role of each subdirectory under the/sys directory. The block directory organizes devices from the point of view of a block device, which organizes devices from the point of view of the system bus, such as a PCI bus or a USB bus; The class directory raises the view of the problem to the category height, such as a PCI device or USB device; The dev directory view is the device node The devices directory, mentioned earlier, is home to all devices; The firmware directory contains relatively low-order subsystems, such as ACPI, EFI, and so on; The FS directory sees all the file systems supported by the system; The kernel directory contains some kernel configuration options The modules directory contains information about all kernel modules, and the kernel module actually has a correspondence with the device, and through this directory it is possible to find devices or vice versa; The Power directory holds the system power management data. It can be used to query the current state of power, or even Direct "command" system into hibernation and other power-saving mode.

Sysfs is a bridge between the user and the kernel device model, through which we can read information from the kernel or write to the kernel.

In Linux, you can also find some graphical tools to query device information. Like the HAL-based device Manager under GNOME:

Or a solid-based kinfocenter under KDE:

These graphical tools provide a more intuitive way to access devices, but they do not provide comprehensive information and do not have the capability to write data to the kernel device.

If specific to a certain type of device, there are some specialized tools available under Linux. For example, pciutils for PCI devices, usbutils for USB devices, and LSSCSI for SCSI devices. For Linux developers, it is sometimes more convenient to use these specialized tools.

If we are going to write a program to access SYSFS, we can manipulate the files in the/sys directory as well as read and write ordinary files, or you can use LIBSYSFS. However, it is important to note that the Linux kernel community does not recommend LIBSYSFS because the API is not updated fast enough to keep up with changes in the kernel. Libsysfs has gradually deviated from the goal of creating it initially, and this lib poses more problems than it solves. Of course, if you just want to access the device, generally rarely directly operate SYSFS, it is too detail too low, in most cases can use more convenient devicekit or Libudev.

In summary, this paper mainly introduces the basic concept of Linux device model and the SYSFS of virtual file system. The next chapter will continue to explore some of the details of the device model in kernel space.

Turn Linux device model (1)