Sysfs File System

By Patrick mochel
Source: Network

Abstract

Sysfs is a feature of the 2.6 kernel. It allows kernel code to report information to the user's process through an in-memory file system. The directory level of the file system (hierarchy) the organization is strict and forms the basis of the internal organization of the kernel data structure. Most files generated in such a file system are ASCII files, and each file usually has a value. These features ensure the accuracy and accessibility of reported information, making sysfs one of the most intuitive and useful features of the 2.6 kernel.

Introduction

Sysfs is a manifestation of kernel objects, attributes, and their relationships. It provides two components: the kernel programming interface reported by these entries through sysfs, and a user interface, used to view and operate the entries mapped to the kernel objects they represent. The following table shows the sysing between internal (kernel) systems and their external (user space) sysfs.

Internal ----- external
Kernel Object --- directory
Object properties-regular files
Object relationship-symbolic connection

Sysfs is a core component of the kernel underlying layer. It provides a simple interface to implement a simple task. There is very little complicated or ambiguous description in the code. However, like many core components at the underlying layer, it will be a little abstract and alienated, so it is difficult to get a clear idea. To reduce the difficulty, this article will give a progressive explanation of sysfs before entering the substantive details.

First, write a short and concise history to describe its origins. Second, it includes key information about sysfs mounting and access, and then describes the directory organization and subsystem layout in sysfs, it provides sufficient information for users to understand the organization and content of the information reported through sysfs. Despite the limitations of time and space, not every object and its attributes will be written.

The primary purpose of this article is to provide a technical perspective for the internal sysfs interface-the data structure and functions used to establish the kernel system to report to the user space, it describes the functions in the three concepts mentioned above (kernel objects, object attributes, and Object Relationships) and sets a chapter for each concept. It also sets a chapter for the other two common file interfaces used to simplify some common operations-attribute groups and binary properties-respectively.

Sysfs is an information channel between the kernel space and the user space. Applications in the user space have many opportunities to use this information, the current exploitation method is the parameter capability of the I/O scheduler and the udev program. The last chapter describes an example of the current application using sysfs and provides a spur to further development in this field.

Because it is a simple and abstract interface, it takes a lot of time to describe the interaction between it and its subsystems. This is especially true for kobject and device model. These two are new features of the 2.6 kernel and closely intertwined with sysfs. Due to space limitations, this article cannot fully discuss these topics, leave them to other articles as themes.
1. sysfs history

Sysfs is an in-memory file system. It was initially based on ramfs. ramfs was written when the kernel of version 2.4.0 was stable, through it, we can see how easy it is to write a simple File System Using VFS layer, which was still a new thing at the time. Because of its simplicity and use of VFS, it has become a good foundation, make other in-memory file systems derived from it.

Sysfs was originally called DDFs (Device Driver File System). It was generated to debug the new driver model being developed. The debugging code initially uses procfs to report the Device Tree, however, with the strict urging of renas * trowaz, it switched to a new ramfs-based file system.

At that time, the new device model was integrated into the kernel (before and after 2.5.1). To make it clearer, the new device model was named driverfs, which was under development in version 2.5 the following year, this device model and underlying features of the device file system prove useful to other subsystems. Kobject is developed to provide a central object management mechanism, while the device file system is converted to sysfs to indicate the unpredictability of its subsystem.

2. sysfs mounting

Sysfs can be mounted from user space like other memory-based file systems:
Mount-T sysfs/sys

Sysfs can also be automatically mounted with the/etc/fstab file at startup. Most distributions that support the 2.6 kernel have sysfs lines in/etc/fstab:
Sysfs/sys sysfs noauto 0 0

Note the directory to which sysfs is mounted:/sys, which is the standard location of sysfs's best load point. This is used by mainstream releases.

3. View sysfs

Since sysfs is a collection of directories, files, and soft connections, you can use a simple shell tool to browse and operate. I recommend using the tree (1) tool, it is the most effective assistant in the development process of the core of the kernel object.

The top layer of the sysfs mount point is a certain number of directories, which represent the main subsystems registered with sysfs. At the time of writing this article, these directories are:
/Sys/
|--Block
|-Bus
|--Class
|--Device
|--Firmware
|-Module
|--Power
These directories are generated at the system startup time when the subsystem registers the kobject core. After they are initialized, they start to search for the objects registered in their respective directories. The method for registering sysfs with an object and how the directory is generated will be explained later. in the meantime, if you are interested, you 'd better examine them at this sysfs level. The following describes the meanings of subsystems and their contents.

3.1
The "Block" directory contains sub-directories of each block device found in the system. Each block Device directory contains various attributes and describes all aspects, from the device size to the dev_t value mapped, there is a soft connection to the physical device mapped to the block device (in the physical device tree, we will talk about it later), there is a directory that reveals the interface of the I/O scheduler, this interface provides some data about the device Request queue and some adjustable features, which can be used by users and administrators to optimize performance, including using them to dynamically change the I/O scheduler. Each Partition Block device is represented as a sub-directory of the block device. These directories contain the read-only attribute of the partition.

Bus 3.2
The "bus" directory contains the subdirectories of each physical bus type supported by kernel registration (Unified compilation or loaded by modules). Some outputs are as follows:
Bus/
|-Ide
|--PCI
|--SCSI
|--USB
Each bus type is listed in two subdirectories: devices and drivers. The devices directory contains a list of devices of this bus type found throughout the system, these listed devices are actually symbolic connections pointing to the Device directory in the global Device Tree. For example:
|--. 0->..././devices/pci0000: 00/0000: 00: 00.0
|--Period :00:01. 0->.../../devices/pci0000: 00/0000: 00: 01.0
|--. 0->..././devices/pci0000: 00/0000: 00: 01.0/. 0
|--. 0->..././devices/pci0000: 00/0000: 00: 1E. 0/0000: 02: 00.0
|--. 1->..././devices/pci0000: 00/0000: 00: 1E. 0/0000: 02: 00.1
|--. 0->..././devices/pci0000: 00/0000: 00: 1E. 0/0000: 02: 01.0
|--. 0->..././devices/pci0000: 00/0000: 00: 1E. 0/0000: 02: 02.0
The DRIVERS directory contains the directory for registering each driver of the bus type. Each driver directory contains the attributes that allow you to view and manipulate device parameters, A soft connection to the physical device to which the device is bound (on the Global Device Tree.

3.3 categories
The "class" directory contains the representation of each device class registered in the kernel. A device class describes a feature type of the device, as shown below:
Class/
|-Graphics
|--Input
|--Net
|--Printer
|--Scsi_device
|--Sound
|--Tty
Each device class contains sub-directories of class objects allocated and registered for that device class, the directories of most Device objects contain soft connections to the device and driver directories associated with the class objects (at the global device level and bus level respectively). Note, the 1:1 ing between a device and a physical device is not necessarily. A physical device may contain multiple class objects to perform different logical functions. For example, a physical mouse maps a kernel mouse object, a generic "input event" device, or a "input debugging" device. Each Class and Class Object contains various attributes. They LIST parameters to describe and control the class object. The content and format are completely dependent on the class and depend on the support stored in the kernel.
(To be continued)