Brief introduction to the basic structure of Linux unified Devices

After a long time learning about Linux unified devices, I would like to share with you that you have certainly gained a lot after reading this article. I hope this article will teach you more things. During the development of the Linux 2.5 kernel, a new device model was designed to uniformly represent and operate all Linux devices on the computer, including the connection between Linux unified devices and devices.

This model is obtained during the analysis of the PCI and USB bus drivers. These two bus types can represent the majority of device types in the current system, they both have sound hot and straight-up mechanisms and support for power management, as well as support for cascading mechanisms, supports more PCI/USB devices in the form of a bridge PCI/USB bus controller. In order to add unified power management support to all devices, rather than allowing each Linux unified device to implement power management support independently, people are considering how to reuse code as much as possible; in addition, in a hierarchical PCI/USB bus, the hierarchical relationship must be displayed in a reasonable form, which is also required by power management and so on.

For example, in a typical PC system, the central processor (CPU) can directly control the PCI bus device, while the USB bus device is a PCI device (PCI-USB Bridge) is connected to the PCI bus device, and the external USB device is connected to the USB bus device. When the computer performs the suspend operation, the Linux kernel should notify each device to suspend power supply in the order of "external USB device-> USB Bus Device-> PCI bus device"; execute resume) otherwise, the device will not be notified of the correct power status change and will not work properly.

Sysfs is a by-product in the development of this Linux unified device model (see the LinuxJournal article written by Greg K. Harman in references ). In order to express these devices with hierarchies in a way visible to the user program, it is natural to think that using the directory tree structure of the file system is the basis for thinking about the problem in UNIX mode, everything is a file !) In this model, there are several basic types of their mappings.

Basic Structure of Linux unified Device Model

The content of the type corresponds to the kernel data structure corresponding to/sys items
A device (Devices) device is the most basic type in this model. It organizes struct device/sys/devices /*/*/.../
Device Drivers Install multiple identical devices in one system. You only need one copy of the driver to support struct device_driver/sys/bus/pci/drivers /*/
Bus Types (bus Types) manage all devices connected to this Bus at the entire bus level struct bus_type/sys/Bus /*/
Device category is a Device Hierarchy Tree organized by function. For example, the mouse of USB interface and PS/2 interface are input devices, it will appear in the/sys/class/input/struct class/sys/class /*/

From the data structure used by the kernel to implement them, the Linux unified device model is structured in two basic data structures:
Kobject: the most basic object in the Linux unified device model. Its function is to provide reference counting and maintain the parent-Child (parent) structure and level (sibling) Directory relationships. The above device, device_driver and other objects are implemented based on the kobject functions; struct kobject {
Const char * name;
Struct list_headentry;
Struct kobject * parent;
Struct kset * kset;
Struct kobj_type * ktype;
Struct sysfs_dirent * sd;
Struct kref;
Unsigned int state_initialized: 1;
Unsigned int state_in_sysfs: 1;
Unsigned int state_add_uevent_sent: 1;
Unsigned int state_remove_uevent_sent: 1;

Here, struct kref contains a atomic_t type for reference counting. parent is a single pointer to the parent node. entry is used for the parent kset to maintain the kobject structure as a two-way linked list in the chain table header structure;
Kset: it is used to provide a packaging set for objects of the same type. In the kernel data structure, it is also implemented by embedding a kboject, therefore, it is also a kobject (inheritance relation in the object-oriented OOP concept), with all the functions of kobject; struct kset {
Struct list_head list;
Spinlock_t list_lock;
Struct kobject kobj;
Struct kset_uevent_ops * uevent_ops;

The struct list_head list is used to maintain the kobject in the set as a bidirectional linked list by struct list_head entry;
When it comes to file system implementation, sysfs is a memory file system implemented based on ramfs. It is similar to other memory file systems (configfs, debugfs, tmpfs,...) implemented using ramfs ,...) similarly, sysfs directly implements various objects in the file system using VFS-level struct such as struct inode and struct dentry in VFS; in addition, a structure called struct sysfs_dirent is used to represent each directory item in/sys on the private data (such as dentry-> d_fsdata) of each file system.
Struct sysfs_dirent {
Atomic_ts_count;
Atomic_ts_active;
Struct sysfs_dirent * s_parent;
Struct sysfs_dirent * s_sibling;
Const char * s_name;
Union {
Struct sysfs_elem_dir s_dir;
Struct sysfs_elem_symlink s_symlink;
Struct sysfs_elem_attr s_attr;
Struct sysfs_elem_bin_attr s_bin_attr;
Unsigned int s_flags;
Ino_t s_ino;
Umode_t s_mode;
Struct iattr * s_iattr;

In the preceding kobject object, we can see a directed sysfs_dirent pointer. Therefore, in sysfs, the same struct sysfs_dirent is used to kset/kobject/attr/attr_group in the Linux unified device model.

Specifically, on the data structure member, sysfs_dirent has a union shared body which contains four different structures: Directory, symbolic link file, attribute file, and Binary Attribute file; the directory type can correspond to kobject, and the corresponding s_dir also has a pointer to kobject. Therefore, in the kernel data structure, kobject and sysfs_dirent are mutually referenced;

The/sys directory structure expressed by sysfs is very clear and clear:
Kset is under the/sys root directory, which organizes the/sys top-level directory view;
In some ksets, There is a level-2 or deeper kset;
Each kset directory contains one or more kobject, which indicates the kobject struct contained in a collection;
There are attrs files and attr_group under kobject. An Attribute Group is a directory of organizational properties, together, they provide the user layer with interfaces for expressing and operating the attribute features of this kobject;
There are also some symbolic link files under kobject that point to other kobject. These symbolic link files are used to organize the relationships between device, driver, bus_type, class, and module mentioned above;
Different types of kobject, such as device type and Device Driver type, have different attributes. sysfs interfaces supported by different drivers also have different attribute files; devices of the same type have many identical property files;
Note: The content of this table is organized according to the update of kernel 2.6.28 in the latest development. It is mentioned in Appendix resources such as LDD3 that there is a management object called subsys (subsystem object) in sysfs ), in the latest kernel, it is not required after reconstruction. Its functions can be completely replaced by kset. That is to say, in sysfs, only one management structure is kset, A structure that represents a specific object is kobject. Under kobject, an attribute file is used to represent the attributes of this object. The preceding section describes Linux unified devices.

1. Top 10 Linux operating system highlights
2. Linux is not your reason
3. Describes the hardware supported by Linux operating system installation and recognition.
4. In Linux, what is Windows?
5. Discuss and test the use of Fedora Linux hardware