Linux内核文档之sysfs文件系统
2021-01-03 22:10:22 
阿炯
sysfs - The filesystem for exporting kernel objects.
sysfs - 用于导出内核对象(kobject)的文件系统。
Sysfs是Linux 2.6所提供的一种虚拟文件系统。这个文件系统不仅可以把设备(devices)和驱动程序(drivers)的信息从内核输出到用户空间，也可以用来对设备和驱动程序做设置。Linux内核开发团队在Linux 2.5的开发过程中引入了“Linux驱动程序模型(Linux driver model)”，以解决2.4核心遭遇的以下的3个问题：
1)、没有统一的机制表达驱动程序和设备的关系。
2)、不存在一般的热插拔(hotplug)机制。
3)、procfs文件系统过度混乱，包含了许多非进程(process)的信息。
Linux 设备模型通过 kobject、kset 和 kobj_type 三个核心对象实现设备层次结构的管理和 sysfs 的集成。
sysfs的作用
暴露设备和驱动信息：用户可以通过 /sys 查看硬件设备（如 CPU、USB、PCI 设备）、内核模块、电源管理等数据。
动态设备管理：支持热插拔（如 U 盘插入时自动在 /sys 和 /dev 生成节点）。
内核与用户空间交互：允许通过读写 /sys 下的文件调整内核参数（如调节屏幕亮度、CPU 频率）。
目录结构简介
按类别组织为多个子目录，主要包含以下核心目录：
sysfs的目的是把一些原本在procfs中的，关于设备的部分，独立出来，以“设备层次结构架构(device tree)”的形式呈现。这个文件系统由Patrick Mochel所写，之后Maneesh Soni撰写“sysfs backing store path”，以降低在大型系统中对存储器的需求量。程序开发层也有提供：SYSFS(5)
sysfs一开始ramfs为基础，也是一个只存在于内存中的文件系统，ramfs是在2.4核心处于稳定阶段时加入的。ramfs是一个优雅的实现，简洁以及使用了VFS，稍后的一些存储器形式的文件系统都以它作为开发基础。
sysfs刚开始被命名成ddfs(Device Driver Filesystem)，当初只是为了要对新的驱动程序模型调试而开发出来的。它在调试时，会把设备架构(device tree)的信息输出到procfs文件系统中。但在Linus Torvalds的急切督促下，ddfs被转型成一个以ramfs为基础的文件系统。在新的驱动程序模型被集成进2.5.1核心时，ddfs被改名成driverfs，以更确切描述它的用途。
在2.5核心开发的次年，新的“驱动程序模型”和"driverfs"证明了对核心中的其他子系统也有用处。kobjects被开发出来，作为核心对象的中央管理机制，而此时driverfs也被改名成sysfs。 每个被加入driver model tree内的对象，包括驱动程序、设备以及class设备，都会在sysfs文件系统中以一个目录呈现。对象的属性作为文件出现，符号链接代表对象间的关系。通常安装在/sys目录下：mount -t sysfs sysfs /sys
Patrick Mochel <mochel@osdl.org>
Mike Murphy <mamurph@cs.clemson.edu>
Revised: 16 August 2011 Original: 10 January 2003
中文版维护者：傅炜 Fu Wei <tekkamanninja@gmail.com>
What it is:
sysfs简介
~~~~~~~~~~~
sysfs is a ram-based filesystem initially based on ramfs. It provides a means to export kernel data structures, their attributes, and the linkages between them to userspace.
sysfs是一个最初基于ramfs并且位于内存的文件系统。它提供导出内核数据结构及其属性，以及它们之间关联到用户空间的方法。
sysfs is tied inherently to the kobject infrastructure. Please read Documentation/kobject.txt for more information concerning the kobject interface.
sysfs始终与kobject的底层结构紧密相关。请阅读Documentation/kobject.txt文档以获得更多关于kobject接口的信息。
Using sysfs
使用sysfs
~~~~~~~~~~~
sysfs is always compiled in if CONFIG_SYSFS is defined. You can access it by doing:
只要内核配置中定义了CONFIG_SYSFS，sysfs将会被编译进内核。你可以通过以下命令挂载它：
mount -t sysfs sysfs /sys
Directory Creation
创建目录
~~~~~~~~~~~~~~~~~~
For every kobject that is registered with the system, a directory is created for it in sysfs. That directory is created as a subdirectory of the kobject's parent, expressing internal object hierarchies to userspace. Top-level directories in sysfs represent the common ancestors of object hierarchies; i.e. the subsystems the objects belong to.
任何kobject在系统中注册后，就会有一个目录在sysfs中被创建。这个目录是作为该kobject的父对象所在目录的子目录创建的，用以准确地传递内核的对象层次到用户空间。sysfs中的顶层目录代表着内核对象层次的共同祖先；例如：某些对象属于某个子系统。
Sysfs internally stores a pointer to the kobject that implements a directory in the kernfs_node object associated with the directory. In the past this kobject pointer has been used by sysfs to do reference counting directly on the kobject whenever the file is opened or closed. With the current sysfs implementation the kobject reference count is only modified directly by the function sysfs_schedule_callback().
sysfs在与其目录关联的sysfs_dirent对象中内部保存一个指向实现目录的kobject的指针。以前，这个kobject指针被sysfs直接用于kobject文件打开和关闭的引用计数。而目前的sysfs实现中，kobject引用计数只能通过sysfs_schedule_callback()函数直接修改。
Attributes
属性
~~~~~~~~~~
Attributes can be exported for kobjects in the form of regular files in the filesystem. Sysfs forwards file I/O operations to methods defined for the attributes, providing a means to read and write kernel attributes.
kobject的属性可在文件系统中以普通文件的形式导出。sysfs为属性定义了面向文件I/O操作的方法，以提供对内核属性的读写。
Attributes should be ASCII text files, preferably with only one value per file. It is noted that it may not be efficient to contain only one value per file, so it is socially acceptable to express an array of values of the same type.
属性应为ASCII码文本文件。以一个文件只存储一个属性值为宜。但一个文件只包含一个属性值可能影响效率，所以一个包含相同数据类型的属性值数组也被广泛地接受。
Mixing types, expressing multiple lines of data, and doing fancy formatting of data is heavily frowned upon. Doing these things may get you publicly humiliated and your code rewritten without notice.
混合类型、表达多行数据以及一些怪异的数据格式会遭到强烈反对。这样做是很丢脸的，而且其代码会在未通知作者的情况下被重写。
An attribute definition is simply:
一个简单的属性结构定义如下：
struct attribute {
char *name;
struct module *owner;
umode_t mode;
};
int sysfs_create_file(struct kobject * kobj, const struct attribute * attr);
void sysfs_remove_file(struct kobject * kobj, const struct attribute * attr);
A bare attribute contains no means to read or write the value of the attribute. Subsystems are encouraged to define their own attribute structure and wrapper functions for adding and removing attributes for a specific object type.
一个单独的属性结构并不包含读写其属性值的方法。子系统最好为增删特定对象类型的属性，而定义自己的属性结构和封装函数。
For example, the driver model defines struct device_attribute like:
例如：驱动程序模型定义的device_attribute结构体如下：
struct device_attribute{
struct attribute attr;
ssize_t (*show)(struct device *dev, struct device_attribute *attr, char *buf);
ssize_t (*store)(struct device *dev, struct device_attribute *attr, const char *buf, size_t count);
};
int device_create_file(struct device *, const struct device_attribute *);
void device_remove_file(struct device *, const struct device_attribute *);
It also defines this helper for defining device attributes:
为了定义设备属性，同时引入了辅助宏：
#define DEVICE_ATTR(_name, _mode, _show, _store) \
struct device_attribute dev_attr_##_name = __ATTR(_name, _mode, _show, _store)
For example, declaring：
例如，下面的声明：
static DEVICE_ATTR(foo, S_IWUSR | S_IRUGO, show_foo, store_foo);
is equivalent to doing:
等同于下面的代码：
static struct device_attribute dev_attr_foo = {
.attr = {
.name = "foo",
.mode = S_IWUSR | S_IRUGO,
},
.show = show_foo,
.store = store_foo,
};
Subsystem-Specific Callbacks
子系统特有的回调函数
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When a subsystem defines a new attribute type, it must implement a set of sysfs operations for forwarding read and write calls to the show and store methods of the attribute owners.
当一个子系统定义一个新的属性类型时，必须实现一系列的sysfs操作，以帮助读写调用去实现属性所有者的显示和存储方法。
struct sysfs_ops{
ssize_t (*show)(struct kobject *, struct attribute *, char *);
ssize_t (*store)(struct kobject *, struct attribute *, const char *, size_t);
};
[ Subsystems should have already defined a struct kobj_type as a descriptor for this type, which is where the sysfs_ops pointer is stored. See the kobject documentation for more information. ]
[子系统应已经定义了一个struct kobj_type结构体作为这个类型的描述符，并在此保存sysfs_ops的指针。更多的信息参见kobject的文档]
When a file is read or written, sysfs calls the appropriate method for the type. The method then translates the generic struct kobject and struct attribute pointers to the appropriate pointer types, and calls the associated methods.
当一个文件被读写时，sysfs会为这个类型调用适当的方法。这个方法会将一般的kobject和attribute结构体指针转换为适当的指针类型后调用相关联的函数。
To illustrate:
示例：
#define to_dev(obj) container_of(obj, struct device, kobj)
#define to_dev_attr(_attr) container_of(_attr, struct device_attribute, attr)
static ssize_t dev_attr_show(struct kobject *kobj, struct attribute *attr, char *buf){
struct device_attribute *dev_attr = to_dev_attr(attr);
struct device *dev = to_dev(kobj);
ssize_t ret = -EIO;
if (dev_attr->show)
ret = dev_attr->show(dev, dev_attr, buf);
if (ret >= (ssize_t)PAGE_SIZE) {
print_symbol("dev_attr_show: %s returned bad count\n", (unsigned long)dev_attr->show);
}
return ret;
}
Reading/Writing Attribute Data
读/写属性数据
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To read or write attributes, show() or store() methods must be specified when declaring the attribute. The method types should be as simple as those defined for device attributes:
在声明属性时，必须指定show()或store()函数，以实现属性的读或写。这些函数的类型应该和以下的设备属性定义一样简单。
ssize_t (*show)(struct device *dev, struct device_attribute *attr, char *buf);
ssize_t (*store)(struct device *dev, struct device_attribute *attr, const char *buf, size_t count);
IOW, they should take only an object, an attribute, and a buffer as parameters.
也就是说，它们应该只以一个处理对象、一个属性和一个缓冲指针作为参数。
sysfs allocates a buffer of size (PAGE_SIZE) and passes it to the method. Sysfs will call the method exactly once for each read or write. This forces the following behavior on the method implementations:
sysfs会分配一个大小为(PAGE_SIZE)的缓冲区并传递给这个函数。sysfs将会为每次读写操作调用一次这个函数。这使得这些函数在执行时会出现下面以下的行为：
- On read(2), the show() method should fill the entire buffer. Recall that an attribute should only be exporting one value, or an array of similar values, so this shouldn't be that expensive.
- 在读方面(read(2))，show()函数应该填充整个缓冲区。前面提到，属性应只导出了一个属性值或是一个同类型属性值的数组，所以这个代价将不会太高。
This allows userspace to do partial reads and forward seeks arbitrarily over the entire file at will. If userspace seeks back to zero or does a pread(2) with an offset of '0' the show() method will be called again, rearmed, to fill the buffer.
这使得用户空间可以局部地读和任意向前搜素整个文件。如果用户空间向后搜索到0或使用”0”偏移执行一个pread(2)操作，show()方法将再次被调用，以重新填充缓存。
- On write(2), sysfs expects the entire buffer to be passed during the first write. Sysfs then passes the entire buffer to the store() method. A terminating null is added after the data on stores. This makes functions like sysfs_streq() safe to use.
- 在写方面(write(2))，sysfs希望第一次写操作时得到整个缓冲区，之后sysfs传递整个缓冲区给store()函数。
When writing sysfs files, userspace processes should first read the entire file, modify the values it wishes to change, then write the entire buffer back.
当要写sysfs文件时，用户空间进程首先读取整个文件，修改需要改变的值后，然后将值回写到整个缓冲区。
Attribute method implementations should operate on an identical buffer when reading and writing values.
当读写属性值时，属性函数的执行应操作相同的缓冲区。
Other notes:
注意：
- Writing causes the show() method to be rearmed regardless of current file position.
- 写操作将导致的show()方法重载，会忽略当前文件位置。
- The buffer will always be PAGE_SIZE bytes in length. On i386, this is 4096.
- 缓冲区应总是PAGE_SIZE的大小。对于i386，这个值为4096。
- show() methods should return the number of bytes printed into the buffer. This is the return value of scnprintf().
- show()函数应该返回写入缓冲区的字节数，也就是scnprintf()的返回值。
- show() must not use snprintf() when formatting the value to be returned to user space. If you can guarantee that an overflow will never happen you can use sprintf() otherwise you must use scnprintf().
- 格式化要返回给用户空间的值时，show()不得使用snprintf()。如果可以保证溢出永远不会发生时，你可以使用sprintf()，否则，你必须使用scnprintf()。
- store() should return the number of bytes used from the buffer. If the entire buffer has been used, just return the count argument.
- store()应返回缓冲区的已用字节数。如果整个缓冲区都已填满，只需要返回count参数。
- show() or store() can always return errors. If a bad value comes through, be sure to return an error.
- show()或store()可以返回错误值。当得到一个非法值，必须返回一个错误值。
- The object passed to the methods will be pinned in memory via sysfs referencing counting its embedded object. However, the physical entity (e.g. device) the object represents may not be present. Be sure to have a way to check this, if necessary.
- 一个传递给函数的对象将会通过sysfs调用对象内嵌的引用计数固定在内存中。尽管如此，对象代表的物理实体(如设备)可能已不存在。如有必要，应该实现一个检测机制。
A very simple (and naive) implementation of a device attribute is:
一个简单的(未经实验证实的)设备属性实现如下：
static ssize_t show_name(struct device *dev, struct device_attribute *attr, char *buf){
return scnprintf(buf, PAGE_SIZE, "%s\n", dev->name);
}
static ssize_t store_name(struct device *dev, struct device_attribute *attr, const char *buf, size_t count){
snprintf(dev->name, sizeof(dev->name), "%.*s", (int)min(count, sizeof(dev->name) - 1), buf);
return count;
}
static DEVICE_ATTR(name, S_IRUGO, show_name, store_name);
(Note that the real implementation doesn't allow userspace to set the name for a device.)
(注意：真正的实现不允许用户空间设置设备名)
Top Level Directory Layout
顶层目录布局
~~~~~~~~~~~~~~~~~~~~~~~~~~
The sysfs directory arrangement exposes the relationship of kernel data structures.
sysfs目录的安排显示了内核数据结构之间的关系。
The top level sysfs directory looks like:
顶层的sysfs目录如下：
block/
bus/
class/
dev/
devices/
firmware/
net/
fs/
devices/ contains a filesystem representation of the device tree. It maps directly to the internal kernel device tree, which is a hierarchy of struct device.
devices/包含了一个设备树的文件系统表示。它直接映射了内部的内核设备树，反映了设备的层次结构。
bus/ contains flat directory layout of the various bus types in the kernel. Each bus's directory contains two subdirectories:
bus/包含了内核中各种总线类型的平面目录布局。每个总线目录包含两个子目录：
devices/
drivers/
devices/ contains symlinks for each device discovered in the system that point to the device's directory under root/.
devices/包含了系统中出现的每个设备的符号链接，它们指向root/下的设备目录。
drivers/ contains a directory for each device driver that is loaded for devices on that particular bus (this assumes that drivers do not span multiple bus types).
drivers/包含了每个已为特定总线上的设备而挂载的驱动程序的目录(这里假设驱动没有跨越多个总线类型)
fs/ contains a directory for some filesystems. Currently each filesystem wanting to export attributes must create its own hierarchy below fs/ (see ./fuse.txt for an example).
fs/包含了一个为文件系统设立的目录。现在，每个想要导出属性的文件系统必须在fs/下创建自己的层次结构(参见Documentation/filesystems/fuse.txt)。
dev/ contains two directories char/ and block/. Inside these two directories there are symlinks named <major>:<minor>. These symlinks point to the sysfs directory for the given device. /sys/dev provides a quick way to lookup the sysfs interface for a device from the result of a stat(2) operation.
dev/包含两个子目录：char/和block/。在这两个子目录中，有以<major>:<minor>格式命名的符号链接。这些符号链接指向sysfs目录中相应的设备。/sys/dev提供一个通过一个stat(2)操作结果，查找设备sysfs接口快捷的方法。
More information can driver-model specific features can be found in Documentation/driver-model/.
更多有关driver-model的特性信息可以在Documentation/driver-model/中找到。
TODO: Finish this section.
完成这一节。
Current Interfaces
目前接口
~~~~~~~~~~~~~~~~~~
The following interface layers currently exist in sysfs:
以下的接口层普遍存在于当前的sysfs中：
- devices (include/linux/device.h)
----------------------------------
Structure:
结构体：
struct device_attribute {
struct attribute attr;
ssize_t (*show)(struct device *dev, struct device_attribute *attr, char *buf);
ssize_t (*store)(struct device *dev, struct device_attribute *attr, const char *buf, size_t count);
};
Declaring:
声明：
DEVICE_ATTR(_name, _mode, _show, _store);
Creation/Removal:
增加/删除属性：
int device_create_file(struct device *dev, const struct device_attribute * attr);
void device_remove_file(struct device *dev, const struct device_attribute * attr);
- bus drivers (include/linux/device.h)
--------------------------------------
Structure:
结构体：
struct bus_attribute {
struct attribute attr;
ssize_t (*show)(struct bus_type *, char * buf);
ssize_t (*store)(struct bus_type *, const char * buf, size_t count);
};
Declaring:
声明：
BUS_ATTR(_name, _mode, _show, _store);
Creation/Removal:
增加/删除属性：
int bus_create_file(struct bus_type *, struct bus_attribute *);
void bus_remove_file(struct bus_type *, struct bus_attribute *);
- device drivers (include/linux/device.h)
-----------------------------------------
Structure:
结构体：
struct driver_attribute {
struct attribute attr;
ssize_t (*show)(struct device_driver *, char * buf);
ssize_t (*store)(struct device_driver *, const char * buf, size_t count);
};
Declaring:
声明：
DRIVER_ATTR_RO(_name) DRIVER_ATTR_RW(_name);
Creation/Removal:
增加/删除属性：
int driver_create_file(struct device_driver *, const struct driver_attribute *);
void driver_remove_file(struct device_driver *, const struct driver_attribute *);
Documentation
文档
~~~~~~~~~~~~~
The sysfs directory structure and the attributes in each directory define an ABI between the kernel and user space. As for any ABI, it is important that this ABI is stable and properly documented. All new sysfs attributes must be documented in Documentation/ABI.See also Documentation/ABI/README for more information.
sysfs目录结构以及其中包含的属性定义了一个内核与用户空间之间的ABI。对于任何ABI，其自身的稳定和适当的文档是非常重要的。所有新的sysfs属性必须在Documentation/ABI中有文档，详见Documentation/ABI/README。
Linux 设备模型
1、设备模型概述
从2.6版本开始，Linux开发团队便为内核建立起一个统一的设备模型。在以前的内核中没有独立的数据结构用来让内核获得系统整体配合的信息。尽管缺乏这些信息，在多数情况下内核还是能正常工作的。然而，随着拓扑结构越来越复杂，以及要支持诸如电源管理等新特性的需求，向新版本的内核明确提出了这样的要求：需要有一个对系统结构的一般性抽象描述，即设备模型。
目的
I、设备、驱动、总线等彼此之间关系错综复杂。如果想让内核运行流畅，那就必须为每个模块编码实现这些功能。如此一来，内核将变得非常臃肿、冗余。而设备模型的理念即是将这些代码抽象成各模块共用的框架，这样不但代码简洁了，也可让设备驱动开发者摆脱这本让人头痛但又必不可少的一劫，将有限的精力放于设备差异性的实现。
II、设备模型用类的思想将具有相似功能的设备放到一起管理，并将相似部分萃取出来，使用一份代码实现。从而使结构更加清晰，简洁。
III、动态分配主从设备号，有效解决设备号的不足。设备模型实现了只有设备在位时才为其分配主从设备号，这与之前版本为每个设备分配一个主从设备号不同，使得有限的资源得到合理利用。
IV、设备模型提供sysfs文件系统，以文件的方式让本是抽象复杂而又无法捉摸的结构清晰可视起来。同时也给用户空间程序配置处于内核空间的设备驱动提供了一个友善的通道。
V、程序具有随意性，同一个功能，不同的人实现的方法和风格各不相同，设备驱动亦是如此。大量的设备亦若实现方法流程均不相同，对以后的管理、重构将是难以想象的工作量。设备模型恰是提供了一个模板，一个被证明过的最优的思路和流程，这减少了开发者设计过程中不必要的错误，也给以后的维护扫除了障碍。
2、设备模型结构
如下表，Linux设备模型包含以下四个基本结构：
device、driver、bus、class是组成设备模型的基本数据结构。kobject是构成这些基本结构的核心，kset又是相同类型结构kobject的集合。kobject和kset共同组成了sysfs的底层数据体系。本节采用从最小数据结构到最终组成一个大的模型的思路来介绍。当然，阅读时也可先从Device、Driver、Bus、Class的介绍开始，先总体了解设备模型的构成，然后再回到kobject和kset，弄清它们是如何将Device、Driver、Bus、Class穿插链接在一起的，以及如何将这些映像成文件并最终形成一个sysfs文件系统。
3、sys 文件系统
sysfs是一个基于内存的文件系统，它的作用是将内核信息以文件的方式提供给用户程序使用。
sysfs可以看成与proc,devfs和devpty同类别的文件系统，该文件系统是虚拟的文件系统，可以更方便对系统设备进行管理。它可以产生一个包含所有系统硬件层次视图，与提供进程和状态信息的proc文件系统十分类似。
sysfs把连接在系统上的设备和总线组织成为一个分级的文件，它们可以由用户空间存取，向用户空间导出内核的数据结构以及它们的属性。sysfs的一个目的就是展示设备驱动模型中各组件的层次关系，其顶级目录包括block,bus,drivers,class,power和firmware等.
sysfs提供一种机制，使得可以显式的描述内核对象、对象属性及对象间关系。sysfs有两组接口，一组针对内核，用于将设备映射到文件系统中，另一组针对用户程序，用于读取或操作这些设备。下表描述了内核中的sysfs要素及其在用户空间的表现：
sysfs目录结构(block bus class dev devices firmware fs kernel module power)：
sysfs是一个特殊文件系统，并没有一个实际存放文件的介质。
1)、kobject结构
sysfs的信息来源是kobject层次结构，读一个sysfs文件，就是动态的从kobject结构提取信息，生成文件。重启后里面的信息当然就没了。
sysfs文件系统与kobject结构紧密关联，每个在内核中注册的kobject对象都对应于sysfs文件系统中的一个目录。Kobject 是Linux 2.6引入的新的设备管理机制，在内核中由struct kobject表示。通过这个数据结构使所有设备在底层都具有统一的接口，kobject提供基本的对象管理，是构成Linux2.6设备模型的核心结构，Kobject是组成设备模型的基本结构。类似于C++中的基类，它嵌入于更大的对象的对象中，用来描述设备模型的组件。如bus,devices, drivers 等。都是通过kobject连接起来了，形成了一个树状结构。这个树状结构就与/sys向对应。
2)、sysfs 如何读写kobject 结构
sysfs就是利用VFS的接口去读写kobject的层次结构，建立起来的文件系统。kobject的层次结构的注册与注销XX_register()形成的。文件系统是个很模糊广泛的概念，linux把所有的资源都看成是文件，让用户通过一个统一的文件系统操作界面，也就是同一组系统调用，对属于不同文件系统的文件进行操作。这样，就可以对用户程序隐藏各种不同文件系统的实现细节，为用户程序提供了一个统一的，抽象的，虚拟的文件系统界面，这就是所谓"VFS(Virtual Filesystem Switch)"。这个抽象出来的接口就是一组函数操作。
要实现一种文件系统就是要实现VFS所定义的一系列接口，file_operations, dentry_operations, inode_operations等，供上层调用。
file_operations是描述对每个具体文件的操作方法(如：读，写)；
dentry_operations结构体指明了VFS所有目录的操作方法；
inode_operations提供所有结点的操作方法。
举个例子，C程序中的文件打开：open(“hello.c”, O_RDONLY)，它通过系统调用的流程是这样的：
open() -> 系统调用-> sys_open() -> filp_open()-> dentry_open() -> file_operations->open()
不同的文件系统，调用不同的file_operations->open()，在sysfs下就是sysfs_open_file()。我们使用不同的文件系统，就是将它们各自的文件信息都抽象到dentry和inode中去。这样对于高层来说，我们就可以不关心底层的实现，我们使用的都是一系列标准的函数调用。这就是VFS的精髓，实际上就是面向对象。
注意：sysfs是典型的特殊文件。它存储的信息都是由系统动态的生成的，它动态的包含了整个机器的硬件资源情况。从sysfs读写就相当于向kobject层次结构提取数据。
---------------------------------------------------------------------
Documentation/ABI/testing/sysfs-block.txt的中文翻译
如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻译存在问题，请联系中文版维护者。中文版翻译维护者(Chinese maintainer)：徐红(1534342777@qq.com)。
以下为正文
---------------------------------------------------------------------
sysfs-块
系统文件——块
--------------------
What:/sys/block/<disk>/stat
Date:February 2008
Contact:Jerome Marchand <jmarchan@redhat.com>
Description:The /sys/block/<disk>/stat files displays the I/O statistics of disk <disk>. They contain 11 fields:
1 - reads completed successfully
2 - reads merged
3 - sectors read
4 - time spent reading (ms)
5 - writes completed
6 - writes merged
7 - sectors written
8 - time spent writing (ms)
9 - I/Os currently in progress
10 - time spent doing I/Os (ms)
11 - weighted time spent doing I/Os (ms)
For more details refer Documentation/iostats.txt
目录：/sys/block/<disk>/stat
日期：2008年2月
联系方式：Jerome Marchand <jmarchan@redhat.com>
摘要：/sys/block/<disk>/stat文件显示了磁盘I/O数据。它们包含了11个区域。
1.完全成功读取
2.混合读取
3.扇区读取
4.读取时间（ms）
5.完全写入
6.混合写入
7.扇区的写入
8.写入时间（ms）
9.当前进度中的I/O设备
10.I/O工作的时间（ms）
11.I/O工作的加权时间（ms）
更多的细节在Documentation/iostats.txt文档中。
What:/sys/block/<disk>/<part>/stat
Date:February 2008
Contact:Jerome Marchand <jmarchan@redhat.com>
Description:The /sys/block/<disk>/<part>/stat files display the I/O statistics of partition <part>. The format is the same as the above-written /sys/block/<disk>/stat format.
目录：/sys/block/<disk>/<part>/stat
日期：2008年2月
联系方式：Jerome Marchand <jmarchan@redhat.com>
摘要：/sys/block/<disk>/<part>/stat文件显示了分区的I/O数据。格式和上面/sys/block/<disk>/stat的格式一样。
What:/sys/block/<disk>/integrity/format
Date:June 2008
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:Metadata format for integrity capable block device.
E.g. T10-DIF-TYPE1-CRC.
目录：/sys/block/<disk>/integrity/format
日期：2008年6月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：块设备完整性的元数据格式。
E.g. T10-DIF-TYPE1-CRC.
What:/sys/block/<disk>/integrity/read_verify
Date:June 2008
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:Indicates whether the block layer should verify the integrity of read requests serviced by devices that support sending integrity metadata.
目录：/sys/block/<disk>/integrity/read_verify
日期：2008年6月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：表明块层是否应该通过支持发送完整元数据的设备来验证读请求服务的完整性。
What:/sys/block/<disk>/integrity/tag_size
Date:June 2008
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:Number of bytes of integrity tag space available per 512 bytes of data.
目录：/sys/block/<disk>/integrity/tag_size
日期：2008年6月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：每512字节数据完整标签可用空间的字节数。
What:/sys/block/<disk>/integrity/write_generate
Date:June 2008
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:Indicates whether the block layer should automatically generate checksums for write requests bound for devices that support receiving integrity metadata.
目录：/sys/block/<disk>/integrity/write_generate
日期：2008年6月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：表明块层是否应该为支持接收完整数据元的写请求约束设备自动生成校验。
What:/sys/block/<disk>/alignment_offset
Date:April 2009
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:Storage devices may report a physical block size that is bigger than the logical block size (for instance a drive with 4KB physical sectors exposing 512-byte logical blocks to the operating system). This parameter indicates how many bytes the beginning of the device is offset from the disk's natural alignment.
目录：/sys/block/<disk>/alignment_offset
日期：2009年4月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：存储设备可能会记录一个比逻辑块大小更大的物理块的大小（例如一个4KB物理扇区的驱动呈现给操作系统的是512B的逻辑块）。这个参数表示设备的开头离磁盘的自然对齐有多少字节的偏移。
What:/sys/block/<disk>/<partition>/alignment_offset
Date:April 2009
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:Storage devices may report a physical block size that is bigger than the logical block size (for instance a drive with 4KB physical sectors exposing 512-byte logical blocks to the operating system). This parameter indicates how many bytes the beginning of the partition is offset from the disk's natural alignment.
目录：/sys/block/<disk>/<partition>/alignment_offset
日期：2009年4月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：存储设备可能会记录一个比逻辑块大小更大的物理块的大小（例如一个4KB物理扇区的驱动呈现给操作系统的是512B的逻辑块）。这个参数表示分区的开头离磁盘的自然对齐有多少字节的偏移。
What:/sys/block/<disk>/queue/logical_block_size
Date:May 2009
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:This is the smallest unit the storage device can address. It is typically 512 bytes.
目录：/sys/block/<disk>/queue/logical_block_size
日期：2009年5月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：这是存储设备最小的可编址单元，通常为512字节。
What:/sys/block/<disk>/queue/physical_block_size
Date:May 2009
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:This is the smallest unit a physical storage device can write atomically. It is usually the same as the logical block size but may be bigger. One example is SATA drives with 4KB sectors that expose a 512-byte logical block size to the operating system. For stacked block devices the physical_block_size variable contains the maximum physical_block_size of the component devices.
目录：/sys/block/<disk>/queue/physical_block_size
日期：2009年5月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：这是一个物理存储设备可自动写入的最小单元，通常和逻辑块大小一样，也可能大一点。比如，4KB扇区的SATA驱动呈现给操作系统一个512B的物理块大小。对于堆块设备，物理块大小的变量包含了组件设备的最大物理块的大小。
What:/sys/block/<disk>/queue/minimum_io_size
Date:April 2009
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:Storage devices may report a granularity or preferred minimum I/O size which is the smallest request the device can perform without incurring a performance penalty. For disk drives this is often the physical block size. For RAID arrays it is often the stripe chunk size. A properly aligned multiple of minimum_io_size is the preferred request size for workloads where a high number of I/O operations is desired.
目录：/sys/block/<disk>/queue/minimum_io_size
日期：2009年4月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：存储设备可能会记录一个粒度或优先级最小的I/O的大小，这是在不导致性能降低的前提下，可执行设备的最小要求。对于磁盘设备，这通常是物理块大小。对于RAID阵列，这通常是条纹快大小。恰当的最小输入输出大小的多重对齐是需要大量I/O操作的工作负载的首选请求。
What:/sys/block/<disk>/queue/optimal_io_size
Date:April 2009
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:Storage devices may report an optimal I/O size, which is the device's preferred unit for sustained I/O. This is rarely reported for disk drives. For RAID arrays it is usually the stripe width or the internal track size. A properly aligned multiple of optimal_io_size is the preferred request size for workloads where sustained throughput is desired. If no optimal I/O size is reported this file contains 0.
目录：/sys/block/<disk>/queue/optimal_io_size
日期：2009年4月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：存储设备可能会记录一个最优I/O大小，这是持续的I/O首选单元。这很少为磁盘驱动记录。对于RAID阵列，这通常是条纹宽度或是内部跟踪大小。恰当的最优输入输出大小的多重对齐是需要持续吞吐量的工作负载的首选请求大小。如果没有记录最优I/O大小，这个文件置为0。
What:/sys/block/<disk>/queue/nomerges
Date:January 2010
Contact:
Description:Standard I/O elevator operations include attempts to merge contiguous I/Os. For known random I/O loads these attempts will always fail and result in extra cycles being spent in the kernel. This allows one to turn off this behavior on one of two ways: When set to 1, complex merge checks are disabled, but the simple one-shot merges with the previous I/O request are enabled. When set to 2,all merge tries are disabled. The default value is 0 which enables all types of merge tries.
目录：/sys/block/<disk>/queue/nomerges
日期：2010年1月
联系方式：
摘要：标准的I/O电梯运行包括尝试合并相邻I/O。对于已知的随机I/O负载，这些尝试通常会失败，并导致额外的周期用于内核。阻止这种行为的两种方式之一：当置为1时，复杂的合并检查被禁用，但是和前面的I/O请求的简单一次性合并被启用。当置为2时，所有的尝试合并都是被禁用的。合并默认值是0——所有类型的尝试合并都被启用。
What:/sys/block/<disk>/discard_alignment
Date:May 2011
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:Devices that support discard functionality may internally allocate space in units that are bigger than the exported logical block size. The discard_alignment parameter indicates how many bytes the beginning of the device is offset from the internal allocation unit's natural alignment.
目录：/sys/block/<disk>/discard_alignment
日期：2011年5月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：支持丢弃功能的设备可能在比导出的逻辑块大的单元内部分配空间。丢弃对齐参数表明设备的开头离内部分配单元的自然对齐的偏移量有多少字节。
What:/sys/block/<disk>/<partition>/discard_alignment
Date:May 2011
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:Devices that support discard functionality may internally allocate space in units that are bigger than the exported logical block size. The discard_alignment parameter indicates how many bytes the beginning of the partition is offset from the internal allocation unit's natural alignment.
目录：/sys/block/<disk>/<partition>/discard_alignment
日期：2011年5月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：支持丢弃功能的设备可能在比导出的逻辑块大的单元内部分配空间。丢弃对齐参数表明分区的开头离内部分配单元的自然对齐的偏移量有多少字节。
What:/sys/block/<disk>/queue/discard_granularity
Date:May 2011
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:Devices that support discard functionality may internally allocate space using units that are bigger than the logical block size. The discard_granularity parameter indicates the size of the internal allocation unit in bytes if reported by the device. Otherwise the discard_granularity will be set to match the device's physical block size. A discard_granularity of 0 means that the device does not support discard functionality.
目录：/sys/block/<disk>/queue/discard_granularity
日期：2011年5月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：支持丢弃功能的设备可能用比逻辑块大的单元在内部分配空间。如果被设备记录，丢弃粒度参数表明内部分配单元以比特位单位的大小。否则，丢弃粒度将会被设置成匹配设备物理块大小的值。丢弃粒度为0表明设备不支持丢弃功能。
What:/sys/block/<disk>/queue/discard_max_bytes
Date:May 2011
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:Devices that support discard functionality may have internal limits on the number of bytes that can be trimmed or unmapped in a single operation. Some storage protocols also have inherent limits on the number of blocks that can be described in a single command. The discard_max_bytes parameter is set by the device driver to the maximum number of bytes that can be discarded in a single operation. Discard requests issued to the device must not exceed this limit. A discard_max_bytes value of 0 means that the device does not support discard functionality.
目录：/sys/block/<disk>/queue/discard_max_bytes
日期：2011年5月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：支持丢弃功能的设备可能在单一操作上能够削减或映射的字节数有内部限制。一些存储协议对于单一命令中能被描述的块的数量也有固定的限制。丢弃最大字节参数被驱动设备设置成在单一操作中能够被丢弃的字节的最大数量。设备发出的丢弃请求不能超过这个限制。丢弃最大字节值为0表明该设备不支持丢弃功能。
What:/sys/block/<disk>/queue/discard_zeroes_data
Date:May 2011
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:Devices that support discard functionality may return stale or random data when a previously discarded block is read back. This can cause problems if the filesystem expects discarded blocks to be explicitly cleared. If a device reports that it deterministically returns zeroes when a discarded area is read the discard_zeroes_data parameter will be set to one. Otherwise it will be 0 and the result of reading a discarded area is undefined.
目录：/sys/block/<disk>/queue/discard_zeroes_data
日期：2011年5月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：支持丢弃功能的设备当之前丢弃的块被读回时，可能返回过期或随机数据。如果文件系统想要显式地丢弃块这样可能会导致问题发生。如果设备报告当丢弃区域被读设备肯定返回0，丢弃零数据参数将被置1。否则将被置为0，并且读丢弃区域的结果是未定义的。
What:/sys/block/<disk>/queue/write_same_max_bytes
Date:January 2012
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:Some devices support a write same operation in which a single data block can be written to a range of several contiguous blocks on storage. This can be used to wipe areas on disk or to initialize drives in a RAID configuration. write_same_max_bytes indicates how many bytes can be written in a single write same command. If write_same_max_bytes is 0, write same is not supported by the device.
目录：/sys/block/<disk>/queue/write_same_max_bytes
日期： 2012年1月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：一些设备在单个数据块可以被写到几个相邻的数据块中的存储器中支持写相同操作。这个可以用来擦除磁盘区域，还可以在RAID配置中初始化驱动器。写相同最大字节表明在一次写相同命令中有多少字节可以被写入。如果写相同最大字节为0，则说明设备不支持写相同。
目录：/proc/diskstats
日期：February 2008
摘要：The /proc/diskstats file displays the I/O statistics of block devices. Each line contains the following 14 fields:
1 major number
2 minor mumber
3 device name
4 reads completed successfully
5 reads merged
6 sectors read
7 time spent reading (ms)
8 writes completed
9 writes merged
10 sectors written
11 time spent writing (ms)
12 I/Os currently in progress
13 time spent doing I/Os (ms)
14 weighted time spent doing I/Os (ms)
== ===================================
Kernel 4.18+ appends four more fields for discard tracking putting the total at 18:
15 discards completed successfully
16 discards merged
17 sectors discarded
18 time spent discarding
== ===================================
Kernel 5.5+ appends two more fields for flush requests:
19 flush requests completed successfully
20 time spent flushing
总结：
sysfs 文件系统对于 Linux 系统至关重要，因为它提供了与内核交互的接口，支持设备管理、调试和动态响应等关键功能节点。/sys 目录是一个重要的虚拟文件系统入口，用于与内核进行交互，并让用户空间（user space）程序能够访问和修改内核内部状态；/sys 目录是 sysfs 文件系统的挂载点。
/sys/devices
该目录是 Linux 系统中的一个虚拟文件系统的一部分，主要用于提供有关系统中物理设备的信息。是 sysfs 文件系统的核心组成部分，允许用户空间程序以一种结构化的方式与内核中的设备和驱动程序进行交互。
1. 结构
/sys/devices 目录的结构非常复杂，通常包含多个子目录和文件，主要可以分为以下几类：
物理设备：每个物理设备（如硬盘、USB 设备、网络接口等）都有一个对应的目录，目录名称通常是设备的唯一标识符（如设备 ID）。
子设备：某些设备可能具有多个子设备，例如，一个 USB 控制器可能连接多个 USB 设备。
类别：设备可能会被分类到不同的类别中，如 class、bus、platform 等。
2. 关键文件与信息
在 /sys/devices 中，提供了有关设备的状态和属性的信息，包括但不限于：
uevent：每个设备都有一个 uevent 文件，用于描述设备事件。当设备的状态发生变化时，相关的信息会写入这个文件，以通知用户空间的程序。
driver：指向该设备驱动程序的链接，显示当前处理该设备的驱动程序。
modalias：用于描述设备的模块别名，帮助内核确定应加载哪个驱动程序。
power：与设备的电源管理相关的文件夹，提供有关设备电源状态的信息，如开启、关闭、休眠等模式。
3. 设备类别
在 /sys/devices 下，设备可以按照不同的类别进行组织，常见的包括：
/sys/devices/pci0000:00/：表示 PCI 设备的层次结构，每个设备都有其特定的路径。
/sys/devices/platform/：表示平台设备，通常是集成在主板上的设备，如 GPIO 控制器。
/sys/devices/usb/...：专门用于 USB 设备的目录，显示所有连接的 USB 设备。
4. 与用户空间的交互
动态性：/sys/devices 是动态更新的，设备的添加和删除会自动反映在该目录中。例如，当插入 USB 设备时，相应的目录会被创建，而当设备被移除时，该目录会被删除。
交互：用户可以通过读取和写入 /sys/devices 中的文件来获取设备状态或配置设备属性。例如，可以通过修改 power 目录中的文件来控制设备的电源管理行为。
/sys/dev
该目录是 Linux 系统中 sysfs 文件系统的一部分，主要用于提供与设备相关的信息和接口。虽然在许多现代 Linux 系统中，设备信息通常位于 /sys/devices 中，但 /sys/dev 目录仍然存在并被用作一些特定设备的接口。
1. 设备分类/sys/dev
目录下的内容通常与设备的类型或类别相关，可能包含多个子目录，每个子目录对应一种设备类型。这些子目录中的文件和子目录提供了关于设备状态、驱动程序、模块和配置参数的信息。
2. 关键文件和信息
在 /sys/dev 目录下，有以下几类重要文件和信息：
uevent：每个设备都有一个 uevent 文件，用于描述设备事件。当设备状态发生变化时，相关的信息会写入这个文件，以通知用户空间的程序。
driver：指向处理该设备的驱动程序的链接。通过这个文件，可以知道哪个驱动正在管理特定设备。
power：与电源管理相关的文件夹，提供有关设备电源状态的信息，允许用户控制设备的电源模式（如开启、关闭、休眠等）。
modalias：描述设备的模块别名，帮助内核确定应加载哪个驱动程序。
3. 与设备的交互
动态性：/sys/dev 是动态更新的，设备的添加和删除会自动反映在该目录中。例如，当插入 USB 设备时，相应的目录会被创建，而当设备被移除时，该目录会被删除。
交互：可以通过读取和写入 /sys/dev 中的文件来获取设备状态或配置设备属性。例如，可以通过修改 power 目录中的文件来控制设备的电源管理行为。
4. 应用场景
调试：开发者可以查看 /sys/dev 中的设备信息，以帮助调试硬件问题或驱动程序问题。
设备管理：系统管理员可以使用 /sys/dev 提供的信息来进行设备监控和管理，例如检查设备是否正常工作或修改设备设置。
编写脚本：开发人员可以编写脚本，通过解析 /sys/dev 中的信息来自动化设备管理任务。
/sys/class
该目录下包含所有注册在kernel里面的设备类型，这是按照设备功能分类的设备模型，每个设备类型表达具有一种功能的设备。每个设备类型子目录下都是这种哦哦那个设备类型的各种具体设备的符号链接，这些链接指向/sys/devices/name下的具体设备。设备类型和设备并没有一一对应的关系，一个物理设备可能具备多种设备类型；一个设备类型只表达具有一种功能的设备，比如：系统所有输入设备都会出现在/sys/class/input之下，而不论它们是以何种总线连接到系统的(/sys/class也是构成linux统一设备模型的一部分)。
其主要用于提供对设备类的访问。这一目录结构允许用户空间程序以统一的方式与不同类型的设备进行交互。是设备类别的抽象表示，每个类别下包含了一组相似设备的接口。
1. 结构
在 /sys/class 中，设备被按照其功能或特性分类，每个子目录代表一个设备类别。例如常见的类别包括：
net：网络接口相关的设备。
tty：终端设备（如串口）。
block：块设备，如硬盘、USB 存储等。
power_supply：电源管理相关的设备，如电池信息。
每个类别下会包含对应设备的符号链接，这些链接指向 /sys/devices 目录中实际的设备实例。
2. 关键功能和内容
2.1 设备接口
在 /sys/class 目录中，每个子目录都包含了与该类别相关的设备的信息，通常会有以下几种重要的文件和符号链接：
符号链接：每个设备类别下的设备通常以符号链接的方式存在。例如，在 /sys/class/net/ 下，每个网络接口的名称（如 eth0 或 wlan0）都是指向 /sys/devices 中实际设备的链接。
属性文件：每个设备都有一些属性文件，通常包括：
uevent：描述设备事件的文件，用于通知用户空间程序设备状态变化。
device：指向设备本身的链接。
driver：指向处理该设备的驱动程序的链接。
power：与电源管理相关的文件夹，提供设备电源状态的信息。
2.2 统一接口
/sys/class 提供了一种统一的方式来访问和管理不同类型的设备。例如，你可以通过访问 /sys/class/net/ 来获取所有网络接口的信息，而不需要具体知道它们在 /sys/devices 中的物理位置。这种抽象使得设备管理变得更加简便和一致。
3. 动态性
/sys/class是动态更新的，设备的添加和删除会实时反映在该目录中。当新的设备被插入时，相应的类别下会创建新的目录和符号链接；当设备被移除时，它们会自动消失。这使得系统能够实时反映设备的状态变化。
4. 使用示例
以下是一些常见的使用场景和命令示例：
查看网络接口：
ls /sys/class/net/
这将列出所有网络接口，例如 eth0 和 wlan0。
获取设备信息：
cat /sys/class/net/eth0/address
这将显示指定网络接口的 MAC 地址。
控制设备：
可以通过写入特定的属性文件来控制设备，例如启用或禁用某个网络接口。
5. 应用场景
设备管理：系统管理员可以通过 /sys/class 获取设备状态和属性信息，以进行监控和管理。
自动化脚本：开发人员可以编写脚本，以读取 /sys/class 中的信息，并自动化设备管理任务。
系统调试：调试设备问题时，可以参考 /sys/class 中的信息，以快速定位问题根源。
注意事项：/sys/class 目录并不直接包含设备的物理信息，它只是对设备进行分类的逻辑表示。所有实际设备信息仍然存储在 /sys/devices 中。
/sys/class 目录为 Linux 系统中的设备管理提供了一个清晰而统一的接口，用户能够方便地访问和控制各种类型的设备。理解其的结构和功能对于系统开发、设备管理和故障排查等方面都是十分重要的。
/sys/block
该目录下的所有子目录代表着系统中当前被发现的所有块设备。按照功能来说防止在/sys/class下会更合适，但由于历史遗留因素而一直存在于/sys/block，但从linux2.6.22内核开始这部分就已经标记为过去时，只有打开了CONFIG_SYSFS_DEPRECATED配置编译才会有这个目录存在，并且其中的内容在从v2.6版本开始已经正式移到了/sys/class/block，旧的接口/sys/block为了向后兼容而保留存在，但其中的内容已经变为了指向它们在/sys/devices/中真实设备的符号链接文件。专门用于提供块设备（block devices）的信息和接口。块设备是可以随机访问的设备，通常用于存储数据，如硬盘、固态硬盘（SSD）、USB 驱动器等。
1. 结构
在 /sys/block 目录下，每个块设备都有一个以设备名称命名的子目录。常见的块设备可能包括：
sda：第一个 SATA 硬盘
sdb：第二个 SATA 硬盘
nvme0n1：第一个 NVMe SSD
每个设备目录中包含了一组文件和子目录，用于描述和管理该块设备。
2. 关键内容和功能
在 /sys/block 中，块设备的每个子目录通常会包含以下几个重要的文件和信息：
2.1 设备属性
size：设备的总大小，以 512 字节块为单位。用户可以通过读取这个文件来获取块设备的总容量。
ro：表示设备是否为只读，若为 1，则设备为只读；若为 0，则设备可读写。
device：指向实际设备的链接，通常指向 /sys/devices 中的相应设备目录。
uevent：用于描述设备事件的文件，当设备状态改变时，可以通过这个文件通知用户空间的程序。
queue：包含与设备 I/O 队列相关的设置和参数，例如调度策略和队列长度。
2.2 I/O 调度
在每个块设备的 /sys/block/<device>/queue 目录下，可以找到与 I/O 调度相关的文件，这些文件允许用户控制和优化设备的 I/O 行为。关键文件包括：
scheduler：当前使用的 I/O 调度器，可以通过写入不同的调度器名称来更改。例如，常见的调度器包括 cfq、deadline、noop。
max_sectors_kb：指定每次 I/O 操作的最大扇区数，通常用于优化性能。
discard_max_bytes：支持 TRIM 操作的块设备的最大字节数，用于 SSD 的垃圾回收。
3. 动态性
/sys/block目录是动态更新的，块设备的添加和删除会实时反映在该目录中。当新设备被连接到系统时，相应的块设备目录会被创建，而当设备被移除时，该目录会被删除。这使得系统能够实时反映设备的状态变化。
4. 使用示例
以下是一些常见的使用场景和命令示例：
查看块设备信息：
ls /sys/block/
这将列出所有块设备，例如 sda、sdb 等。
获取设备大小：
cat /sys/block/sda/size
这将显示 sda 设备的总大小（以 512 字节块为单位）。
检查设备只读状态：
cat /sys/block/sda/ro
这将返回 0 或 1，指示 sda 是否为只读。
更改 I/O 调度器：
echo deadline > /sys/block/sda/queue/scheduler
这将把 sda 设备的 I/O 调度器更改为 deadline。
5. 应用场景
设备监控：系统管理员可以通过 /sys/block 获取块设备的状态和属性信息，以进行监控和管理。
性能优化：开发人员可以调整 I/O 调度器和其他参数，以优化块设备的性能。
故障排查：在调试块设备问题时，可以参考 /sys/block 中的信息，以帮助定位问题。
注意事项：/sys/block 目录只包含块设备的逻辑视图，实际设备信息仍然存储在 /sys/devices 中。
该目录为 Linux 系统中的块设备管理提供了一个清晰而统一的接口，使用户能够方便地访问和控制各种块设备。理解 /sys/block 的结构和功能对于系统开发、设备管理和故障排查等方面都是十分重要的。
/sys/bus
该目录下的每个子目录都是kernel支持并且已经注册了的总线类型。这是内核设备按照总线类型分层放置的目录结构，其中的所有设备都是连接于某种总线之下的，bus子目录下的每种具体总线之下可以找到每个具体设备的符号链接，一般来说每个子目录(总线类型)下包含两个子目录，一个是devices，另一个是drivers；其中devices下是这个总线类型下的所有设备，这些设备都是符号链接，它们分别指向真正的设备(/sys/devices/name/下)；而drivers下是所有注册在这个总线上的驱动，每个driver子目录下是一些可以观察和修改的driver参数。主要用于设备模型和设备驱动的管理，通过文件系统接口向用户空间暴露内核对象（如设备、驱动程序等）的信息。
/sys/bus 目录下包含了与系统中各种总线相关的信息和接口，主要包括以下几个子目录：
1. subsystem: 该目录包含各类总线的子系统，例如 PCI、USB、I2C 等。在这些子目录中，可以找到与特定总线相关的设备和驱动程序的信息。
2. <bus_name>: 每个总线类型在此目录下都有一个相应的子目录。例如：
/sys/bus/pci：与 PCI 总线相关的信息。
/sys/bus/usb：与 USB 总线相关的信息。
/sys/bus/i2c：与 I2C 总线相关的信息。
总线类型示例
1、PCI 总线 (/sys/bus/pci):
该目录下包含了与 PCI 设备相关的信息。你可以找到每个 PCI 设备的详细信息，包括设备 ID、厂商 ID、状态等。
例如，使用 ls /sys/bus/pci/devices/ 可以列出所有 PCI 设备。
2、USB 总线 (/sys/bus/usb):
包含了 USB 设备的信息。你可以查看已连接 USB 设备的详细信息。
文件如 devices/ 下会列出 USB 设备，drivers/ 下会列出相关 USB 驱动程序。
3、I2C 总线 (/sys/bus/i2c):
包括与 I2C 设备相关的信息，显示 I2C 设备的地址、类型等。
关键文件
每个总线目录下通常包含以下关键文件和目录：
devices/: 列出了该总线上连接的所有设备，每个设备都有一个对应的目录，里面包含该设备的属性文件。
drivers/: 列出了可以与该总线上的设备交互的所有驱动程序。
bind/unbind: 这两个文件用于将设备绑定到驱动程序或将其解绑。通过写入设备的名称或 ID，可以手动进行绑定或解绑操作。
uevent: 该文件用于生成 uevent，通常用于设备热插拔事件的通知。
使用示例
1. 查看 PCI 设备:
ls /sys/bus/pci/devices/
2. 查看 USB 设备信息:
ls /sys/bus/usb/devices/
3. 绑定设备到驱动:
echo "<device_id>" > /sys/bus/pci/drivers/<driver_name>/bind
4. 解绑设备:
echo "<device_id>" > /sys/bus/pci/drivers/<driver_name>/unbind
/sys/bus目录是 Linux 内核中处理设备和驱动的重要组成部分，它通过 sysfs 提供了一个统一的接口，让用户能够以文件系统的方式访问和管理系统中的设备。用户可以通过这个目录，可以获得系统设备的详细信息，并对设备进行管理和控制。在设备驱动开发和系统调试中，这个目录提供了很大的帮助。
/sys/fs
该目录使用来描述系统中所有的文件系统，包括文件系统本身和按照文件系统分类存放的已挂载点。主要用于管理和提供文件系统相关的信息和接口。目录下包含了与不同类型的文件系统相关的子目录和信息，允许用户以文件系统的方式访问内核内部的数据结构和状态。
在 /sys/fs 目录下通常会看到一些关于文件系统的子目录。其中最常用的包括：
1. /sys/fs/fscache:
这个目录与文件系统缓存（fscache）相关，用于管理和提供有关文件系统缓存的信息。它包含了缓存对象的状态以及所使用的缓存策略的信息。可以通过这个目录监控哪些文件系统正在使用缓存，以及缓存的使用情况。
2. /sys/fs/cgroup:
cgroup（控制组）是 Linux 内核的一种功能，用于限制、记录、隔离进程组的资源使用（如 CPU、内存等）。
/sys/fs/cgroup 目录用于管理控制组及其层次结构。在这里可以找到关于各个 cgroup 的子系统的信息，并能对 cgroup 进行创建、删除和配置。
3. /sys/fs/selinux:
该目录用于与 SELinux（安全增强型 Linux）相关的信息和配置。SELinux 是一种强制访问控制（MAC）机制，提供了更细粒度的权限控制。/sys/fs/selinux 中包含了 SELinux 的状态信息、策略和上下文等。
4. /sys/fs/ext4 (或其他文件系统类型):
如果系统中挂载了 ext4 文件系统，可能会看到一个名为 /sys/fs/ext4 的目录。这个目录提供了与 ext4 文件系统相关的特定信息，例如挂载选项、日志状态等。
关键功能和文件
每个子目录中通常包含以下关键文件和信息：
状态信息: 各个目录通常会有状态信息文件，显示当前的配置和状态。
控制文件: 用于调整或配置相应的功能。例如，在 /sys/fs/cgroup 中，可以通过写入特定值来设置资源限制。
属性文件: 包含有关特定文件系统的详细属性，如大小、类型、使用情况等。
使用示例
1. 查看 cgroup 信息:
ls /sys/fs/cgroup/
2. 查看 SELinux 状态:
cat /sys/fs/selinux/enforce
3. 查看 fscache 状态:
ls /sys/fs/fscache/
在 Linux 中 /sys/fs 目录的地位其实非常重要，它为文件系统和各种管理功能，提供了一套统一、规范的访问接口。不管是普通用户还是管理员，都能通过它方便地查看、控制文件系统的状态、性能和相关配置。所以不管是日常运维、问题调试，还是做底层开发，搞懂其中的内容和用途是特别关键。
/sys/kernel
这个目录下存放的是内核中所有可调整的参数。其把内核的运行状态、各类配置参数，通过文件系统的形式开放给用户空间。不管是系统管理员还是内核开发者，都能通过这个目录方便地查看和内核行为、调试信息、性能监控相关的内容。
该目录通常包含以下几个重要的子目录和文件：
1. /sys/kernel/hostname ：系统主机名（最常用）
作用：实时查看 / 临时修改当前系统主机名
类型：可读可写
查看：cat /sys/kernel/hostname
临时修改：echo "new-hostname" > /sys/kernel/hostname
对比和 hostname 命令等价，本质就是读写这个文件。
2. /sys/kernel/printk 内核日志输出级别（排错神器）
控制内核日志（dmesg）的输出级别，决定哪些内核信息会打印到控制台、日志文件。
文件包含 4 个数字（以空格分隔）：
控制台日志级别 | 默认消息级别 | 最低控制台级别 | 引导时默认级别
常用操作（临时调高日志，方便排错）：
# 查看当前级别
cat /sys/kernel/printk
# 临时打开全部内核日志（调试用）
echo "8 8 8 8" > /sys/kernel/printk
场景：驱动加载异常、内核报错、启动问题排查必备。
3. /sys/kernel/mm/ 内存管理子系统（性能调优核心）
mm = Memory Management，内存管理的全部可调参数都在这里，是服务器性能优化高频目录。
常用子项：
/sys/kernel/mm/transparent_hugepage/：透明大页 THP（影响 Redis/MySQL/Nginx 性能）
/sys/kernel/mm/min_free_kbytes：系统保留最小空闲内存（防 OOM、防业务卡顿）
/sys/kernel/mm/oom_kill_allocating_task：OOM 时杀死分配内存的进程（快速定位内存溢出）
/sys/kernel/mm/page_size：系统默认页大小（通常 4KB）
示例（查看透明大页状态）：
mount -t debugfs none /sys/kernel/debug
4. /sys/kernel/debug/ 内核调试文件系统（debug 专用）
作用：内核开发者 / 高级排错用，挂载后暴露内核内部数据结构、锁状态、栈跟踪、驱动状态
默认不一定挂载，手动挂载：
mount -t debugfs none /sys/kernel/debug
场景：驱动崩溃、内核死锁、性能 profiling（perf 配合使用）
注意：生产环境默认不建议常开，有安全与性能开销。
5. /sys/kernel/sched/ CPU 调度器配置（高并发优化）
控制 Linux 进程 / 线程调度策略，对高并发、低延迟服务（网关、数据库、消息队列）至关重要。
常用：
/sys/kernel/sched/wakeup_granularity_ns：唤醒粒度（影响调度延迟）
/sys/kernel/sched/min_granularity_ns：最小调度粒度
/sys/kernel/sched/rt_*：实时进程调度相关
6. /sys/kernel/security/ 安全相关（SELinux/AppArmor/LSM）
内核安全模块接口：
/sys/kernel/security/selinux/：SELinux 状态与配置
/sys/kernel/security/apparmor/：AppArmor 安全策略
查看 SELinux 状态：
cat /sys/kernel/security/selinux/enforce
7. /sys/kernel/power/ 电源管理（笔记本 / 嵌入式常用）
控制休眠、待机、电源状态：
/sys/kernel/power/state：设置休眠状态（disk/mem/off）
/sys/kernel/power/suspend_time：睡眠相关计时
服务器一般很少动，嵌入式 / 桌面常用。
8. /sys/kernel/cgroup/ 控制组（容器 / 云原生核心）
cgroup v1/v2 接口，Docker/K8s 资源限制（CPU / 内存 / IO）的底层实现就在此处。
容器的 CPU 限额、内存限流、POD 隔离，本质都是读写 /sys/kernel/cgroup 下的文件。
9. 其他文件
/sys/kernel/osrelease：内核版本（同 uname -r）
/sys/kernel/version：内核编译版本信息
/sys/kernel/modprobe：模块加载相关
/sys/kernel/uevent：硬件热插拔事件（内核与 udev 通信）
关键文件和功能
状态信息: 每个子目录通常包含许多状态信息文件，这些文件显示内核当前的配置和状态。例如，在 /sys/kernel/debug 下，你可以找到特定硬件的调试信息。
控制文件: 文件如 /sys/kernel/printk 提供了控制内核日志行为的接口。这使得在调试时可以灵活地调整信息的详细程度。
调试信息: /sys/kernel/debug 是进行内核调试的重要位置，尤其对开发者和系统管理员来说，能够帮助定位问题和分析性能。
实际应用
1. 内核调试:
开发驱动程序时，可以利用 /sys/kernel/debug 中的信息来检查驱动是否正常工作。使用 ftrace 进行函数跟踪，以优化性能。
2. 性能监控:
通过 /sys/kernel/perf 跟踪性能计数器，分析 CPU 的使用情况。在高负荷情况下，可以监控内存分配情况，确保没有出现内存泄漏。
3. 系统配置:
修改 /sys/kernel/printk 的设置，可以帮助识别在启动过程中遇到的问题，特别是在引导失败时。
/sys/kernel 是 Linux 内核非常关键的一个目录，它直接向外部提供了一套查看和管理内核运行状态的文件接口。借助目录里的各类信息可以很方便地监控系统性能、排查内核问题，甚至调整内核的运行行为。不管是日常运维、内核开发还是故障定位，搞懂其结构和用途，都特别重要。
/sys/firmware
该目录下包含对固件对象(firmware object)和属性进行操作和观察的接口，即这里是系统加载固件机制的对用户空间的接口。是查看和管理固件信息的关键入口。像 UEFI、设备树（Device Tree）这类固件相关内容，都能在这个目录下找到。它对我们管理系统启动、排查和调试固件问题有很大帮助。
以下是 /sys/firmware 目录中常见的子目录和文件的详细介绍：
1. /sys/firmware/efi
描述: 这个目录包含与 UEFI 固件相关的信息。UEFI 是现代计算机的固件接口，取代了传统的 BIOS。
常用文件 / 子目录：
/sys/firmware/efi/systab：UEFI 系统表地址，内核用于和 UEFI 交互。
/sys/firmware/efi/efivars/：UEFI 变量存储目录（最重要）。存放启动项、安全启动、固件参数等 UEFI 变量，efibootmgr 命令就是读写这个目录。
/sys/firmware/efi/config_table：UEFI 配置表信息。
使用示例:
# 查看是否为 UEFI 启动（有目录则是）
ls /sys/firmware/efi
# 查看 UEFI 变量
ls /sys/firmware/efi/efivars/
2. /sys/firmware/devicetree
描述: 此目录包含设备树（Device Tree）相关的信息。设备树是一种数据结构，用于描述硬件设备的配置，特别是在嵌入式系统中。
核心目录：
/sys/firmware/devicetree/base/：设备树根节点，包含所有硬件描述。
model：设备型号（如树莓派 4B）。
compatible：设备兼容属性。
serial-number：设备序列号。
子节点：cpu、memory、uart、gpio 等硬件信息。
使用示例:
# 查看设备型号
cat /sys/firmware/devicetree/base/model
# 查看内存配置
ls /sys/firmware/devicetree/base/memory
3. /sys/firmware/acpi
描述: 该目录包含与 ACPI（高级配置和电源接口）相关的信息。ACPI 是一种用于电源管理和硬件配置的标准。
常用内容：
/sys/firmware/acpi/tables/：存放系统所有 ACPI 表（DSDT、SSDT 等），硬件兼容性调试必备。
/sys/firmware/acpi/interrupts/：ACPI 中断信息。
/sys/firmware/acpi/power_resource/：电源资源管理。
作用：排查服务器无法休眠、电源管理异常、硬件识别失败时，必查这个目录。
使用示例:
ls /sys/firmware/acpi/
cat /sys/firmware/acpi/tables/* # 查看所有 ACPI 表
4. /sys/firmware/dmi（硬件信息，x86 桌面 / 服务器）
DMI（桌面管理接口）是固件记录硬件出厂信息的模块，常用的 dmidecode 命令就是读取这个目录的数据。
存放信息：主板型号、厂商、序列号、BIOS 版本、发布日期、处理器、内存、机箱信息
常用文件：
/sys/firmware/dmi/tables/smbios_entry_point：SMBIOS 入口点。
/sys/firmware/dmi/entries/：按类型分类的 DMI 条目。
作用：无需安装工具，直接读取硬件出厂信息，适合自动化脚本。
5. 其他常见子目录
/sys/firmware/meminit：内核启动时内存初始化相关信息。
/sys/firmware/qemu_fw_cfg：QEMU 虚拟机固件配置接口，虚拟机专用。
/sys/firmware/opal：IBM Power 平台专用固件接口。
功能和用途
1. 固件变量管理:
通过 /sys/firmware/efi/efivars 目录，可以管理 EFI 变量，这对于定制系统启动过程、配置安全启动等非常重要。
2. 设备树支持:
在嵌入式系统中，设备树提供了一种描述和配置硬件的平台无关的方法，使得 Linux 内核能够更灵活地支持多种硬件。
3. 电源管理:
ACPI 相关的信息可以帮助系统管理员和开发者优化电源使用，监控系统的电源状态，确保高效的电源管理。
4. 调试和故障排查:
可以通过查看固件和设备树信息来调试硬件问题、启动失败等故障，为开发和维护提供支持。
实际应用
1. 修改启动选项:
使用 efivars 目录中的变量，可以改变系统的启动顺序或启用/禁用安全启动等功能。
2. 检查硬件配置:
通过设备树信息，可以确认系统是否正确识别了所有硬件组件，并且能够配置它们。
3. ACPI 监控:
监控 ACPI 表和状态，可以帮助管理员了解系统的电源使用情况，并进行相应的优化。
注意事项
1、绝大多数文件只读，不要强行修改
固件信息固化在硬件 / 固件中，修改 /sys/firmware 不会改变底层配置，还可能导致内核异常。
2、平台不同，内容差异极大
不要在 x86 机器找 devicetree，也不要在 ARM 板卡找 efi。
3、排查启动 / 硬件问题的关键目录
开机异常、电源管理失效、硬件识别失败，优先查看 /sys/firmware 下的日志和表信息。
4、普通用户可查看，无需 root
该目录默认开放读权限，普通用户也能查看信息且无需 sudo。
/sys/hypervisor
该目录是与开源虚拟机监视器虚拟化Xen相关的装置。用于访问 Linux 中的虚拟化与 Hypervisor 信息，仅在支持虚拟化的内核中存在，助于快速获取 KVM、Xen、VMware 等虚拟化环境的详细状态与配置。
hypervisor 目录通常包含以下几个子目录和文件：
1. /sys/hypervisor/type
描述: 这个文件指示当前正在使用的虚拟化技术类型，例如 kvm、xen、vmware 等。
内容: 文件内容是一个字符串，表明当前系统使用的程序类型。
使用示例:cat /sys/hypervisor/type
2. /sys/hypervisor/version
描述: 该文件包含当前虚拟化环境的版本信息。
内容: 通常是一个字符串，表示版本号。
使用示例:cat /sys/hypervisor/version
3. /sys/hypervisor/uuid
描述: 这个文件存储当前虚拟机监视器的唯一标识符（UUID）。
内容: UUID 是一个唯一的字符串，用于标识特定的虚拟化环境实例。
使用示例:cat /sys/hypervisor/uuid
4. /sys/hypervisor/identification/
描述：该文件通常包含虚拟化环境的相关识别信息，如供应商名称、版本、特定配置选项等。这些信息有助于用户理解当前正在运行的虚拟化平台的具体实现及其特性。
使用示例：
# 查看厂商和产品名称
cat /sys/hypervisor/identification/vendor
cat /sys/hypervisor/identification/product_name
功能和用途
1. 识别虚拟化类型:
通过检查 /sys/hypervisor/type 文件，系统管理员和开发者可以快速确认正在使用的虚拟化平台。这在进行系统调试和优化时非常有用。
2. 版本管理:
/sys/hypervisor/version 文件可以帮助用户了解当前虚拟化环境的版本，以便于进行更新和维护。确保使用最新的稳定版本可以提高安全性和性能。
3. 唯一标识:
UUID 提供了一种可靠的方式来标识特定的虚拟化环境，这在管理多个虚拟机或在云环境中部署时尤其重要。通过 UUID可以跟踪和管理不同的虚拟机实例。
实际应用
1. 虚拟化监控:
管理员可以使用这些信息来监控和管理其虚拟化环境，确保所有组件正常运行。
2. 故障排除:
在出现问题时，了解虚拟化类型和版本可以帮助快速定位故障原因，并寻找解决方案。
3. 系统配置:
在配置和调整虚拟机设置时，了解当前运行的超管程序类型可以指导用户选择合适的配置选项。
/sys/module
该目录下有系统中所有的模块信息，不论这些模块是以内联(inlined)方式编译到内核映像文件中还是编译为外模块(.ko文件)，都可能出现在/sys/module中。即module目录下包含了所有的被载入kernel的模块。它提供了关于内核模块的信息，内核模块是可加载的代码段，允许动态扩展内核功能而无需重新编译或重启系统。通过 /sys/module 目录，用户和开发者可以查看和管理当前加载的内核模块及其相关信息。
该目录包含以已加载模块名称命名的子目录，每个子目录都代表一个内核模块，并包含该模块的相关信息。这些子目录通常包括以下几个文件和子目录：
1. 模块名称子目录
每个已加载的内核模块都有一个对应的目录，名称与模块相同。如果加载了名为 kvm 的模块，那么将有一个 /sys/module/kvm 目录。
2. /sys/module/<module_name>/parameters
描述: 这个目录包含模块参数的信息。某些模块在加载时可以接受参数以修改其行为。
内容: 每个参数通常是一个文件，文件名为参数名称，文件内容表示当前参数值。
使用示例:cat /sys/module/<module_name>/parameters/<parameter_name>
3. /sys/module/<module_name>/taint
描述: 此文件指示内核模块是否导致内核进入“污染”状态。污染状态通常表明内核正在运行非开源或不受支持的代码。
内容: 通常是一个数字，表示污染类型。
4. /sys/module/<module_name>/initstate
描述: 此文件指示模块的初始化状态。
内容: 内容可能是 live、unloading 或 dead，分别表示模块处于活动、卸载或未加载状态。
5. /sys/module/<module_name>/refcnt
描述: 表示当前引用计数，即有多少个进程或其他模块正在使用该模块。
内容: 一个整数值，指示引用计数。
功能和用途
1. 查看已加载模块:
通过检查 `/sys/module` 目录，用户可以快速查看所有已加载的内核模块，了解系统的当前状态。
2. 管理模块参数:
用户可以访问模块参数以调整模块行为。通过修改这些参数，可以优化性能或启用/禁用特定功能。
3. 调试和故障排除:
在进行系统调试时，查看模块的状态、引用计数和污染状态可以帮助定位问题。
4. 开发和测试:
开发人员可以利用此目录中的信息来测试和验证新开发的内核模块，确保它们正确加载并按预期工作。
实际应用
1. 动态模块管理:
使用 modprobe、insmod 和 rmmod 命令管理模块时，可以通过 /sys/module 验证模块的加载和状态。
2. 性能调优:
通过调整模块参数，如网络驱动程序的缓冲区大小，可以提高系统性能。
3. 安全审计:
检查模块的污染状态可以帮助管理员识别潜在的安全风险，确保系统运行在安全的内核环境中。
/sys/power
该目录是系统中的电源选项，对正在使用的power子系统的描述。这个目录下有几个属性文件可以用于控制整个机器的电源状态，如可以向其中写入控制命令让机器关机/重启等等。是 Linux 系统中用于管理电源管理相关功能的一个重要部分。它提供了一个接口来控制和查询系统的电源状态、睡眠模式和其他电源管理特性。通过这个目录，用户和开发者可以对系统进行电源管理，优化能耗，特别是在笔记本电脑和移动设备上。
目录结构
/sys/power 目录通常包含以下几个文件和子目录：
1. sleep
描述:此文件用于控制系统的休眠（sleep）行为。
内容:可以写入特定的命令来使系统进入不同的休眠状态，例如 disk（将系统写入磁盘休眠）、mem（进入内存休眠）。
使用示例:echo 'disk' > /sys/power/sleep
2. state
描述:此文件提供当前电源状态的信息。
内容:包含系统的当前电源状态，如 active、suspend 等。
使用示例:cat /sys/power/state
3. wantrun
描述: 此文件用于指示是否有待处理的进程希望系统保持活动状态。
内容: 该文件通常会被进程写入特定值，以请求系统不进入低功耗状态。
使用示例:echo '0' > /sys/power/wantrun # 请求系统可以进入低功耗状态
4. pm_test
描述: 这个文件用于测试电源管理功能，而不实际进入低功耗状态。
内容: 允许用户进行测试，比如设置为 platform（测试平台电源管理），而不改变当前状态。
使用示例:echo 'platform' > /sys/power/pm_test
5. sleep_stats
描述: 这个文件记录有关系统进入和退出睡眠状态的统计信息。
内容: 包含有关系统休眠次数和持续时间的详细信息，可用于监控和优化电源管理。
使用示例:cat /sys/power/sleep_stats
关键功能和用途
1. 电源管理控制:
通过 /sys/power 目录中的文件，用户可以直接控制系统的电源管理行为，例如进入休眠模式或获取电源状态。
2. 优化能耗:
了解和调整系统的电源状态可以帮助用户在移动设备上延长电池寿命，减少能耗。
3. 故障排除:
监控休眠状态和统计信息有助于识别电源管理问题，确保系统能够有效地进入和退出休眠模式。
4. 调试和开发:
开发人员可以利用这些接口来测试新电源管理功能或调试现有的电源管理实现。
实际应用
1. 休眠功能:
在笔记本电脑上，用户可以通过 /sys/power/sleep 文件控制何时进入休眠状态，从而节省电池电量。
2. 系统监控:
系统管理员可以定期检查 /sys/power/sleep_stats 来获取系统的电源管理性能数据，以便进行优化。
3. 测试新特性:
在开发新的电源管理驱动程序时，可以使用 /sys/power/pm_test 文件进行实验，而不影响生产环境。
本文部分参考自互联网，感谢原作者及译者。
sysfs - 用于导出内核对象(kobject)的文件系统。
Sysfs是Linux 2.6所提供的一种虚拟文件系统。这个文件系统不仅可以把设备(devices)和驱动程序(drivers)的信息从内核输出到用户空间，也可以用来对设备和驱动程序做设置。Linux内核开发团队在Linux 2.5的开发过程中引入了“Linux驱动程序模型(Linux driver model)”，以解决2.4核心遭遇的以下的3个问题：
1)、没有统一的机制表达驱动程序和设备的关系。
2)、不存在一般的热插拔(hotplug)机制。
3)、procfs文件系统过度混乱，包含了许多非进程(process)的信息。
Linux 设备模型通过 kobject、kset 和 kobj_type 三个核心对象实现设备层次结构的管理和 sysfs 的集成。
sysfs的作用
暴露设备和驱动信息：用户可以通过 /sys 查看硬件设备（如 CPU、USB、PCI 设备）、内核模块、电源管理等数据。
动态设备管理：支持热插拔（如 U 盘插入时自动在 /sys 和 /dev 生成节点）。
内核与用户空间交互：允许通过读写 /sys 下的文件调整内核参数（如调节屏幕亮度、CPU 频率）。
目录结构简介
按类别组织为多个子目录，主要包含以下核心目录：
| 目录 | 用途 |
| /sys/devices | 所有物理设备的层次结构（按总线、设备类型组织）。 |
| /sys/bus | 按总线类型（如 pci、usb、i2c）分类的设备。 |
| /sys/class | 按功能分类的设备（如 net、input、block），符号链接到 /sys/devices。 |
| /sys/block | 块设备（如硬盘、分区）。 |
| /sys/module | 已加载的内核模块信息。 |
| /sys/power | 电源管理（如休眠、唤醒）。 |
| /sys/kernel | 内核运行时参数（如调试选项）。 |
| /sys/firmware | 固件信息（如 ACPI、DTB）。 |
sysfs的目的是把一些原本在procfs中的，关于设备的部分，独立出来，以“设备层次结构架构(device tree)”的形式呈现。这个文件系统由Patrick Mochel所写，之后Maneesh Soni撰写“sysfs backing store path”，以降低在大型系统中对存储器的需求量。程序开发层也有提供：SYSFS(5)
sysfs一开始ramfs为基础，也是一个只存在于内存中的文件系统，ramfs是在2.4核心处于稳定阶段时加入的。ramfs是一个优雅的实现，简洁以及使用了VFS，稍后的一些存储器形式的文件系统都以它作为开发基础。
sysfs刚开始被命名成ddfs(Device Driver Filesystem)，当初只是为了要对新的驱动程序模型调试而开发出来的。它在调试时，会把设备架构(device tree)的信息输出到procfs文件系统中。但在Linus Torvalds的急切督促下，ddfs被转型成一个以ramfs为基础的文件系统。在新的驱动程序模型被集成进2.5.1核心时，ddfs被改名成driverfs，以更确切描述它的用途。
在2.5核心开发的次年，新的“驱动程序模型”和"driverfs"证明了对核心中的其他子系统也有用处。kobjects被开发出来，作为核心对象的中央管理机制，而此时driverfs也被改名成sysfs。 每个被加入driver model tree内的对象，包括驱动程序、设备以及class设备，都会在sysfs文件系统中以一个目录呈现。对象的属性作为文件出现，符号链接代表对象间的关系。通常安装在/sys目录下：mount -t sysfs sysfs /sys
Patrick Mochel <mochel@osdl.org>
Mike Murphy <mamurph@cs.clemson.edu>
Revised: 16 August 2011 Original: 10 January 2003
中文版维护者：傅炜 Fu Wei <tekkamanninja@gmail.com>
What it is:
sysfs简介
~~~~~~~~~~~
sysfs is a ram-based filesystem initially based on ramfs. It provides a means to export kernel data structures, their attributes, and the linkages between them to userspace.
sysfs是一个最初基于ramfs并且位于内存的文件系统。它提供导出内核数据结构及其属性，以及它们之间关联到用户空间的方法。
sysfs is tied inherently to the kobject infrastructure. Please read Documentation/kobject.txt for more information concerning the kobject interface.
sysfs始终与kobject的底层结构紧密相关。请阅读Documentation/kobject.txt文档以获得更多关于kobject接口的信息。
Using sysfs
使用sysfs
~~~~~~~~~~~
sysfs is always compiled in if CONFIG_SYSFS is defined. You can access it by doing:
只要内核配置中定义了CONFIG_SYSFS，sysfs将会被编译进内核。你可以通过以下命令挂载它：
mount -t sysfs sysfs /sys
Directory Creation
创建目录
~~~~~~~~~~~~~~~~~~
For every kobject that is registered with the system, a directory is created for it in sysfs. That directory is created as a subdirectory of the kobject's parent, expressing internal object hierarchies to userspace. Top-level directories in sysfs represent the common ancestors of object hierarchies; i.e. the subsystems the objects belong to.
任何kobject在系统中注册后，就会有一个目录在sysfs中被创建。这个目录是作为该kobject的父对象所在目录的子目录创建的，用以准确地传递内核的对象层次到用户空间。sysfs中的顶层目录代表着内核对象层次的共同祖先；例如：某些对象属于某个子系统。
Sysfs internally stores a pointer to the kobject that implements a directory in the kernfs_node object associated with the directory. In the past this kobject pointer has been used by sysfs to do reference counting directly on the kobject whenever the file is opened or closed. With the current sysfs implementation the kobject reference count is only modified directly by the function sysfs_schedule_callback().
sysfs在与其目录关联的sysfs_dirent对象中内部保存一个指向实现目录的kobject的指针。以前，这个kobject指针被sysfs直接用于kobject文件打开和关闭的引用计数。而目前的sysfs实现中，kobject引用计数只能通过sysfs_schedule_callback()函数直接修改。
Attributes
属性
~~~~~~~~~~
Attributes can be exported for kobjects in the form of regular files in the filesystem. Sysfs forwards file I/O operations to methods defined for the attributes, providing a means to read and write kernel attributes.
kobject的属性可在文件系统中以普通文件的形式导出。sysfs为属性定义了面向文件I/O操作的方法，以提供对内核属性的读写。
Attributes should be ASCII text files, preferably with only one value per file. It is noted that it may not be efficient to contain only one value per file, so it is socially acceptable to express an array of values of the same type.
属性应为ASCII码文本文件。以一个文件只存储一个属性值为宜。但一个文件只包含一个属性值可能影响效率，所以一个包含相同数据类型的属性值数组也被广泛地接受。
Mixing types, expressing multiple lines of data, and doing fancy formatting of data is heavily frowned upon. Doing these things may get you publicly humiliated and your code rewritten without notice.
混合类型、表达多行数据以及一些怪异的数据格式会遭到强烈反对。这样做是很丢脸的，而且其代码会在未通知作者的情况下被重写。
An attribute definition is simply:
一个简单的属性结构定义如下：
struct attribute {
char *name;
struct module *owner;
umode_t mode;
};
int sysfs_create_file(struct kobject * kobj, const struct attribute * attr);
void sysfs_remove_file(struct kobject * kobj, const struct attribute * attr);
A bare attribute contains no means to read or write the value of the attribute. Subsystems are encouraged to define their own attribute structure and wrapper functions for adding and removing attributes for a specific object type.
一个单独的属性结构并不包含读写其属性值的方法。子系统最好为增删特定对象类型的属性，而定义自己的属性结构和封装函数。
For example, the driver model defines struct device_attribute like:
例如：驱动程序模型定义的device_attribute结构体如下：
struct device_attribute{
struct attribute attr;
ssize_t (*show)(struct device *dev, struct device_attribute *attr, char *buf);
ssize_t (*store)(struct device *dev, struct device_attribute *attr, const char *buf, size_t count);
};
int device_create_file(struct device *, const struct device_attribute *);
void device_remove_file(struct device *, const struct device_attribute *);
It also defines this helper for defining device attributes:
为了定义设备属性，同时引入了辅助宏：
#define DEVICE_ATTR(_name, _mode, _show, _store) \
struct device_attribute dev_attr_##_name = __ATTR(_name, _mode, _show, _store)
For example, declaring：
例如，下面的声明：
static DEVICE_ATTR(foo, S_IWUSR | S_IRUGO, show_foo, store_foo);
is equivalent to doing:
等同于下面的代码：
static struct device_attribute dev_attr_foo = {
.attr = {
.name = "foo",
.mode = S_IWUSR | S_IRUGO,
},
.show = show_foo,
.store = store_foo,
};
Subsystem-Specific Callbacks
子系统特有的回调函数
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When a subsystem defines a new attribute type, it must implement a set of sysfs operations for forwarding read and write calls to the show and store methods of the attribute owners.
当一个子系统定义一个新的属性类型时，必须实现一系列的sysfs操作，以帮助读写调用去实现属性所有者的显示和存储方法。
struct sysfs_ops{
ssize_t (*show)(struct kobject *, struct attribute *, char *);
ssize_t (*store)(struct kobject *, struct attribute *, const char *, size_t);
};
[ Subsystems should have already defined a struct kobj_type as a descriptor for this type, which is where the sysfs_ops pointer is stored. See the kobject documentation for more information. ]
[子系统应已经定义了一个struct kobj_type结构体作为这个类型的描述符，并在此保存sysfs_ops的指针。更多的信息参见kobject的文档]
When a file is read or written, sysfs calls the appropriate method for the type. The method then translates the generic struct kobject and struct attribute pointers to the appropriate pointer types, and calls the associated methods.
当一个文件被读写时，sysfs会为这个类型调用适当的方法。这个方法会将一般的kobject和attribute结构体指针转换为适当的指针类型后调用相关联的函数。
To illustrate:
示例：
#define to_dev(obj) container_of(obj, struct device, kobj)
#define to_dev_attr(_attr) container_of(_attr, struct device_attribute, attr)
static ssize_t dev_attr_show(struct kobject *kobj, struct attribute *attr, char *buf){
struct device_attribute *dev_attr = to_dev_attr(attr);
struct device *dev = to_dev(kobj);
ssize_t ret = -EIO;
if (dev_attr->show)
ret = dev_attr->show(dev, dev_attr, buf);
if (ret >= (ssize_t)PAGE_SIZE) {
print_symbol("dev_attr_show: %s returned bad count\n", (unsigned long)dev_attr->show);
}
return ret;
}
Reading/Writing Attribute Data
读/写属性数据
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To read or write attributes, show() or store() methods must be specified when declaring the attribute. The method types should be as simple as those defined for device attributes:
在声明属性时，必须指定show()或store()函数，以实现属性的读或写。这些函数的类型应该和以下的设备属性定义一样简单。
ssize_t (*show)(struct device *dev, struct device_attribute *attr, char *buf);
ssize_t (*store)(struct device *dev, struct device_attribute *attr, const char *buf, size_t count);
IOW, they should take only an object, an attribute, and a buffer as parameters.
也就是说，它们应该只以一个处理对象、一个属性和一个缓冲指针作为参数。
sysfs allocates a buffer of size (PAGE_SIZE) and passes it to the method. Sysfs will call the method exactly once for each read or write. This forces the following behavior on the method implementations:
sysfs会分配一个大小为(PAGE_SIZE)的缓冲区并传递给这个函数。sysfs将会为每次读写操作调用一次这个函数。这使得这些函数在执行时会出现下面以下的行为：
- On read(2), the show() method should fill the entire buffer. Recall that an attribute should only be exporting one value, or an array of similar values, so this shouldn't be that expensive.
- 在读方面(read(2))，show()函数应该填充整个缓冲区。前面提到，属性应只导出了一个属性值或是一个同类型属性值的数组，所以这个代价将不会太高。
This allows userspace to do partial reads and forward seeks arbitrarily over the entire file at will. If userspace seeks back to zero or does a pread(2) with an offset of '0' the show() method will be called again, rearmed, to fill the buffer.
这使得用户空间可以局部地读和任意向前搜素整个文件。如果用户空间向后搜索到0或使用”0”偏移执行一个pread(2)操作，show()方法将再次被调用，以重新填充缓存。
- On write(2), sysfs expects the entire buffer to be passed during the first write. Sysfs then passes the entire buffer to the store() method. A terminating null is added after the data on stores. This makes functions like sysfs_streq() safe to use.
- 在写方面(write(2))，sysfs希望第一次写操作时得到整个缓冲区，之后sysfs传递整个缓冲区给store()函数。
When writing sysfs files, userspace processes should first read the entire file, modify the values it wishes to change, then write the entire buffer back.
当要写sysfs文件时，用户空间进程首先读取整个文件，修改需要改变的值后，然后将值回写到整个缓冲区。
Attribute method implementations should operate on an identical buffer when reading and writing values.
当读写属性值时，属性函数的执行应操作相同的缓冲区。
Other notes:
注意：
- Writing causes the show() method to be rearmed regardless of current file position.
- 写操作将导致的show()方法重载，会忽略当前文件位置。
- The buffer will always be PAGE_SIZE bytes in length. On i386, this is 4096.
- 缓冲区应总是PAGE_SIZE的大小。对于i386，这个值为4096。
- show() methods should return the number of bytes printed into the buffer. This is the return value of scnprintf().
- show()函数应该返回写入缓冲区的字节数，也就是scnprintf()的返回值。
- show() must not use snprintf() when formatting the value to be returned to user space. If you can guarantee that an overflow will never happen you can use sprintf() otherwise you must use scnprintf().
- 格式化要返回给用户空间的值时，show()不得使用snprintf()。如果可以保证溢出永远不会发生时，你可以使用sprintf()，否则，你必须使用scnprintf()。
- store() should return the number of bytes used from the buffer. If the entire buffer has been used, just return the count argument.
- store()应返回缓冲区的已用字节数。如果整个缓冲区都已填满，只需要返回count参数。
- show() or store() can always return errors. If a bad value comes through, be sure to return an error.
- show()或store()可以返回错误值。当得到一个非法值，必须返回一个错误值。
- The object passed to the methods will be pinned in memory via sysfs referencing counting its embedded object. However, the physical entity (e.g. device) the object represents may not be present. Be sure to have a way to check this, if necessary.
- 一个传递给函数的对象将会通过sysfs调用对象内嵌的引用计数固定在内存中。尽管如此，对象代表的物理实体(如设备)可能已不存在。如有必要，应该实现一个检测机制。
A very simple (and naive) implementation of a device attribute is:
一个简单的(未经实验证实的)设备属性实现如下：
static ssize_t show_name(struct device *dev, struct device_attribute *attr, char *buf){
return scnprintf(buf, PAGE_SIZE, "%s\n", dev->name);
}
static ssize_t store_name(struct device *dev, struct device_attribute *attr, const char *buf, size_t count){
snprintf(dev->name, sizeof(dev->name), "%.*s", (int)min(count, sizeof(dev->name) - 1), buf);
return count;
}
static DEVICE_ATTR(name, S_IRUGO, show_name, store_name);
(Note that the real implementation doesn't allow userspace to set the name for a device.)
(注意：真正的实现不允许用户空间设置设备名)
Top Level Directory Layout
顶层目录布局
~~~~~~~~~~~~~~~~~~~~~~~~~~
The sysfs directory arrangement exposes the relationship of kernel data structures.
sysfs目录的安排显示了内核数据结构之间的关系。
The top level sysfs directory looks like:
顶层的sysfs目录如下：
block/
bus/
class/
dev/
devices/
firmware/
net/
fs/
devices/ contains a filesystem representation of the device tree. It maps directly to the internal kernel device tree, which is a hierarchy of struct device.
devices/包含了一个设备树的文件系统表示。它直接映射了内部的内核设备树，反映了设备的层次结构。
bus/ contains flat directory layout of the various bus types in the kernel. Each bus's directory contains two subdirectories:
bus/包含了内核中各种总线类型的平面目录布局。每个总线目录包含两个子目录：
devices/
drivers/
devices/ contains symlinks for each device discovered in the system that point to the device's directory under root/.
devices/包含了系统中出现的每个设备的符号链接，它们指向root/下的设备目录。
drivers/ contains a directory for each device driver that is loaded for devices on that particular bus (this assumes that drivers do not span multiple bus types).
drivers/包含了每个已为特定总线上的设备而挂载的驱动程序的目录(这里假设驱动没有跨越多个总线类型)
fs/ contains a directory for some filesystems. Currently each filesystem wanting to export attributes must create its own hierarchy below fs/ (see ./fuse.txt for an example).
fs/包含了一个为文件系统设立的目录。现在，每个想要导出属性的文件系统必须在fs/下创建自己的层次结构(参见Documentation/filesystems/fuse.txt)。
dev/ contains two directories char/ and block/. Inside these two directories there are symlinks named <major>:<minor>. These symlinks point to the sysfs directory for the given device. /sys/dev provides a quick way to lookup the sysfs interface for a device from the result of a stat(2) operation.
dev/包含两个子目录：char/和block/。在这两个子目录中，有以<major>:<minor>格式命名的符号链接。这些符号链接指向sysfs目录中相应的设备。/sys/dev提供一个通过一个stat(2)操作结果，查找设备sysfs接口快捷的方法。
More information can driver-model specific features can be found in Documentation/driver-model/.
更多有关driver-model的特性信息可以在Documentation/driver-model/中找到。
TODO: Finish this section.
完成这一节。
Current Interfaces
目前接口
~~~~~~~~~~~~~~~~~~
The following interface layers currently exist in sysfs:
以下的接口层普遍存在于当前的sysfs中：
- devices (include/linux/device.h)
----------------------------------
Structure:
结构体：
struct device_attribute {
struct attribute attr;
ssize_t (*show)(struct device *dev, struct device_attribute *attr, char *buf);
ssize_t (*store)(struct device *dev, struct device_attribute *attr, const char *buf, size_t count);
};
Declaring:
声明：
DEVICE_ATTR(_name, _mode, _show, _store);
Creation/Removal:
增加/删除属性：
int device_create_file(struct device *dev, const struct device_attribute * attr);
void device_remove_file(struct device *dev, const struct device_attribute * attr);
- bus drivers (include/linux/device.h)
--------------------------------------
Structure:
结构体：
struct bus_attribute {
struct attribute attr;
ssize_t (*show)(struct bus_type *, char * buf);
ssize_t (*store)(struct bus_type *, const char * buf, size_t count);
};
Declaring:
声明：
BUS_ATTR(_name, _mode, _show, _store);
Creation/Removal:
增加/删除属性：
int bus_create_file(struct bus_type *, struct bus_attribute *);
void bus_remove_file(struct bus_type *, struct bus_attribute *);
- device drivers (include/linux/device.h)
-----------------------------------------
Structure:
结构体：
struct driver_attribute {
struct attribute attr;
ssize_t (*show)(struct device_driver *, char * buf);
ssize_t (*store)(struct device_driver *, const char * buf, size_t count);
};
Declaring:
声明：
DRIVER_ATTR_RO(_name) DRIVER_ATTR_RW(_name);
Creation/Removal:
增加/删除属性：
int driver_create_file(struct device_driver *, const struct driver_attribute *);
void driver_remove_file(struct device_driver *, const struct driver_attribute *);
Documentation
文档
~~~~~~~~~~~~~
The sysfs directory structure and the attributes in each directory define an ABI between the kernel and user space. As for any ABI, it is important that this ABI is stable and properly documented. All new sysfs attributes must be documented in Documentation/ABI.See also Documentation/ABI/README for more information.
sysfs目录结构以及其中包含的属性定义了一个内核与用户空间之间的ABI。对于任何ABI，其自身的稳定和适当的文档是非常重要的。所有新的sysfs属性必须在Documentation/ABI中有文档，详见Documentation/ABI/README。
Linux 设备模型
1、设备模型概述
从2.6版本开始，Linux开发团队便为内核建立起一个统一的设备模型。在以前的内核中没有独立的数据结构用来让内核获得系统整体配合的信息。尽管缺乏这些信息，在多数情况下内核还是能正常工作的。然而，随着拓扑结构越来越复杂，以及要支持诸如电源管理等新特性的需求，向新版本的内核明确提出了这样的要求：需要有一个对系统结构的一般性抽象描述，即设备模型。
目的
I、设备、驱动、总线等彼此之间关系错综复杂。如果想让内核运行流畅，那就必须为每个模块编码实现这些功能。如此一来，内核将变得非常臃肿、冗余。而设备模型的理念即是将这些代码抽象成各模块共用的框架，这样不但代码简洁了，也可让设备驱动开发者摆脱这本让人头痛但又必不可少的一劫，将有限的精力放于设备差异性的实现。
II、设备模型用类的思想将具有相似功能的设备放到一起管理，并将相似部分萃取出来，使用一份代码实现。从而使结构更加清晰，简洁。
III、动态分配主从设备号，有效解决设备号的不足。设备模型实现了只有设备在位时才为其分配主从设备号，这与之前版本为每个设备分配一个主从设备号不同，使得有限的资源得到合理利用。
IV、设备模型提供sysfs文件系统，以文件的方式让本是抽象复杂而又无法捉摸的结构清晰可视起来。同时也给用户空间程序配置处于内核空间的设备驱动提供了一个友善的通道。
V、程序具有随意性，同一个功能，不同的人实现的方法和风格各不相同，设备驱动亦是如此。大量的设备亦若实现方法流程均不相同，对以后的管理、重构将是难以想象的工作量。设备模型恰是提供了一个模板，一个被证明过的最优的思路和流程，这减少了开发者设计过程中不必要的错误，也给以后的维护扫除了障碍。
2、设备模型结构
如下表，Linux设备模型包含以下四个基本结构：
类型 | 所包含的内容 | 内核数据结构 | 对应/sys项 |
设备(Devices) | 设备是此模型中最基本的类型，以设备本身的连接按层次组织 | struct device | /sys/devices/*/*/.../ |
驱动(Drivers) | 在一个系统中安装多个相同设备，只需要一份驱动程序的支持 | struct device_driver | /sys/bus/pci/drivers/*/ |
总线(Bus) | 在整个总线级别对此总线上连接的所有设备进行管理 | struct bus_type | /sys/bus/*/ |
类别(Classes) | 这是按照功能进行分类组织的设备层次树；如 USB 接口和 PS/2 接口的鼠标都是输入设备，都会出现在/sys/class/input/下 | struct class | /sys/class/*/ |
device、driver、bus、class是组成设备模型的基本数据结构。kobject是构成这些基本结构的核心，kset又是相同类型结构kobject的集合。kobject和kset共同组成了sysfs的底层数据体系。本节采用从最小数据结构到最终组成一个大的模型的思路来介绍。当然，阅读时也可先从Device、Driver、Bus、Class的介绍开始，先总体了解设备模型的构成，然后再回到kobject和kset，弄清它们是如何将Device、Driver、Bus、Class穿插链接在一起的，以及如何将这些映像成文件并最终形成一个sysfs文件系统。
3、sys 文件系统
sysfs是一个基于内存的文件系统，它的作用是将内核信息以文件的方式提供给用户程序使用。
sysfs可以看成与proc,devfs和devpty同类别的文件系统，该文件系统是虚拟的文件系统，可以更方便对系统设备进行管理。它可以产生一个包含所有系统硬件层次视图，与提供进程和状态信息的proc文件系统十分类似。
sysfs把连接在系统上的设备和总线组织成为一个分级的文件，它们可以由用户空间存取，向用户空间导出内核的数据结构以及它们的属性。sysfs的一个目的就是展示设备驱动模型中各组件的层次关系，其顶级目录包括block,bus,drivers,class,power和firmware等.
sysfs提供一种机制，使得可以显式的描述内核对象、对象属性及对象间关系。sysfs有两组接口，一组针对内核，用于将设备映射到文件系统中，另一组针对用户程序，用于读取或操作这些设备。下表描述了内核中的sysfs要素及其在用户空间的表现：
sysfs在内核中的组成要素 | 在用户空间的显示 |
内核对象(kobject) | 目录 |
对象属性(attribute) | 文件 |
对象关系(relationship) | 链接(Symbolic Link) |
sysfs目录结构(block bus class dev devices firmware fs kernel module power)：
| /sys下的子目录 | 所包含的内容 |
| /sys/devices | 这是内核对系统中所有设备的分层次表达模型，也是/sys文件系统管理设备的最重要的目录结构；sys文件系统最重要的目录结构，该目录下是全局设备结构体系，包含所有被发现的注册在各种总线上的各种物理设备。一般来说，所有的物理设备都按其在总线上的拓扑结构来显示，但有两个例外，即platform devices和system devices。platform devices一般是挂在芯片内部的高速或者低速总线上的各种控制器和外设，它们能被CPU直接寻；system devices不是外设，而是芯片内部的核心结构，比如CPU，timer等，它们一般没有相关的驱动，但是会有一些体系结构相关的代码来配置它们。 |
/sys/dev | 这个目录下维护一个按字符设备和块设备的主次号码(major:minor)链接到真实的设备(/sys/devices下)的符号链接文件；该目录下有字符设备(block)和块设备(char)两个子目录，里面全是以主次设备号(major:minor)命名的链接文件，链接到/sys/devices。 |
/sys/bus | 这是内核设备按总线类型分层放置的目录结构， devices 中的所有设备都是连接于某种总线之下，在这里的每一种具体总线之下可以找到每一个具体设备的符号链接，它也是构成 Linux 统一设备模型的一部分。按总线类型分类设备，一般来说每个子目录(总线类型)下包含两个子目录，一个是devices，另一个是drivers，其中devices下是这个总线类型下的所有设备，这些设备都是符号链接，它们分别指向真正的设备(/sys/devices/…下)；而drivers下是所有注册在这个总线上的驱动，每个driver子目录下 是一些可以观察和修改的driver参数。 |
/sys/class | 这是按照设备功能分类的设备模型，如系统所有输入设备都会出现在/sys/class/input 之下，而不论它们是以何种总线连接到系统，它也是构成 Linux 统一设备模型的一部分；按功能分类设备，该目录下包含所有注册在kernel里面的设备类型，每个设备类型表达具有一种功能的设备。每个设备类型子目录下是具体设备的符号链接，这些链接指向/sys/devices/…下的具体设备。设备类型和设备并没有一一对应的关系，一个物理设备可能具备多种设备类型，一个设备类型只表达具有一种功能的设备，比如：系统所有输入设备都会出现在/sys/class/input之下，而不论它们是以何种总线连接到系统的(/sys/class也是构成linux统一设备模型的一部分)。 |
/sys/kernel | 这里是内核所有可调整参数的位置，目前只有 uevent_helper, kexec_loaded, mm, 和新式的slab 分配器等几项较新的设计在使用它，其它内核可调整参数仍然位于sysctl(/proc/sys/kernel) 接口中； |
/sys/module | 这里有系统中所有模块的信息，不论这些模块是以内联(inlined)方式编译到内核映像文件(vmlinuz)中还是编译为外部模块(ko文件)，都可能会出现在/sys/module 中：
|
| /sys/power | 这里是系统中电源选项，这个目录下有几个属性文件可以用于控制整个机器的电源状态，如可以向其中写入控制命令让机器关机、重启等。 |
| /sys/block | 从linux2.6.26版本开始已经移到了/sys/class/block。代表着系统中当前被发现的所有块设备。按照功能来说防止在/sys/class下会更合适，但由于历史遗留因素而一直存在于/sys/block，但从linux2.6.22内核开始这部分就已经标记为过去时，只有打开了CONFIG_SYSFS_DEPRECATED配置编译才会有这个目录存在，并且其中的内容在从linux2.6.26版本开始已经正式移到了/sys/class/block，旧的接口/sys/block为了向后兼容而保留存在，但其中的内容已经变为了指向它们在/sys/devices/中真实设备的符号链接文件。 |
| /sys/fs | 该目录用来描述系统中所有的文件系统，包括文件系统本身和按照文件系统分类存放的已挂载点。 |
| /sys/firmware | 该目录下包含对固件对象(firmware object)和属性进行操作和观察的接口，即这里是系统加载固件机制的对用户空间的接口(关于固件有专用于固件加载的一套API)。 |
sysfs是一个特殊文件系统，并没有一个实际存放文件的介质。
1)、kobject结构
sysfs的信息来源是kobject层次结构，读一个sysfs文件，就是动态的从kobject结构提取信息，生成文件。重启后里面的信息当然就没了。
sysfs文件系统与kobject结构紧密关联，每个在内核中注册的kobject对象都对应于sysfs文件系统中的一个目录。Kobject 是Linux 2.6引入的新的设备管理机制，在内核中由struct kobject表示。通过这个数据结构使所有设备在底层都具有统一的接口，kobject提供基本的对象管理，是构成Linux2.6设备模型的核心结构，Kobject是组成设备模型的基本结构。类似于C++中的基类，它嵌入于更大的对象的对象中，用来描述设备模型的组件。如bus,devices, drivers 等。都是通过kobject连接起来了，形成了一个树状结构。这个树状结构就与/sys向对应。
2)、sysfs 如何读写kobject 结构
sysfs就是利用VFS的接口去读写kobject的层次结构，建立起来的文件系统。kobject的层次结构的注册与注销XX_register()形成的。文件系统是个很模糊广泛的概念，linux把所有的资源都看成是文件，让用户通过一个统一的文件系统操作界面，也就是同一组系统调用，对属于不同文件系统的文件进行操作。这样，就可以对用户程序隐藏各种不同文件系统的实现细节，为用户程序提供了一个统一的，抽象的，虚拟的文件系统界面，这就是所谓"VFS(Virtual Filesystem Switch)"。这个抽象出来的接口就是一组函数操作。
要实现一种文件系统就是要实现VFS所定义的一系列接口，file_operations, dentry_operations, inode_operations等，供上层调用。
file_operations是描述对每个具体文件的操作方法(如：读，写)；
dentry_operations结构体指明了VFS所有目录的操作方法；
inode_operations提供所有结点的操作方法。
举个例子，C程序中的文件打开：open(“hello.c”, O_RDONLY)，它通过系统调用的流程是这样的：
open() -> 系统调用-> sys_open() -> filp_open()-> dentry_open() -> file_operations->open()
不同的文件系统，调用不同的file_operations->open()，在sysfs下就是sysfs_open_file()。我们使用不同的文件系统，就是将它们各自的文件信息都抽象到dentry和inode中去。这样对于高层来说，我们就可以不关心底层的实现，我们使用的都是一系列标准的函数调用。这就是VFS的精髓，实际上就是面向对象。
注意：sysfs是典型的特殊文件。它存储的信息都是由系统动态的生成的，它动态的包含了整个机器的硬件资源情况。从sysfs读写就相当于向kobject层次结构提取数据。
---------------------------------------------------------------------
Documentation/ABI/testing/sysfs-block.txt的中文翻译
如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻译存在问题，请联系中文版维护者。中文版翻译维护者(Chinese maintainer)：徐红(1534342777@qq.com)。
以下为正文
---------------------------------------------------------------------
sysfs-块
系统文件——块
--------------------
What:/sys/block/<disk>/stat
Date:February 2008
Contact:Jerome Marchand <jmarchan@redhat.com>
Description:The /sys/block/<disk>/stat files displays the I/O statistics of disk <disk>. They contain 11 fields:
1 - reads completed successfully
2 - reads merged
3 - sectors read
4 - time spent reading (ms)
5 - writes completed
6 - writes merged
7 - sectors written
8 - time spent writing (ms)
9 - I/Os currently in progress
10 - time spent doing I/Os (ms)
11 - weighted time spent doing I/Os (ms)
For more details refer Documentation/iostats.txt
目录：/sys/block/<disk>/stat
日期：2008年2月
联系方式：Jerome Marchand <jmarchan@redhat.com>
摘要：/sys/block/<disk>/stat文件显示了磁盘I/O数据。它们包含了11个区域。
1.完全成功读取
2.混合读取
3.扇区读取
4.读取时间（ms）
5.完全写入
6.混合写入
7.扇区的写入
8.写入时间（ms）
9.当前进度中的I/O设备
10.I/O工作的时间（ms）
11.I/O工作的加权时间（ms）
更多的细节在Documentation/iostats.txt文档中。
What:/sys/block/<disk>/<part>/stat
Date:February 2008
Contact:Jerome Marchand <jmarchan@redhat.com>
Description:The /sys/block/<disk>/<part>/stat files display the I/O statistics of partition <part>. The format is the same as the above-written /sys/block/<disk>/stat format.
目录：/sys/block/<disk>/<part>/stat
日期：2008年2月
联系方式：Jerome Marchand <jmarchan@redhat.com>
摘要：/sys/block/<disk>/<part>/stat文件显示了分区的I/O数据。格式和上面/sys/block/<disk>/stat的格式一样。
What:/sys/block/<disk>/integrity/format
Date:June 2008
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:Metadata format for integrity capable block device.
E.g. T10-DIF-TYPE1-CRC.
目录：/sys/block/<disk>/integrity/format
日期：2008年6月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：块设备完整性的元数据格式。
E.g. T10-DIF-TYPE1-CRC.
What:/sys/block/<disk>/integrity/read_verify
Date:June 2008
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:Indicates whether the block layer should verify the integrity of read requests serviced by devices that support sending integrity metadata.
目录：/sys/block/<disk>/integrity/read_verify
日期：2008年6月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：表明块层是否应该通过支持发送完整元数据的设备来验证读请求服务的完整性。
What:/sys/block/<disk>/integrity/tag_size
Date:June 2008
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:Number of bytes of integrity tag space available per 512 bytes of data.
目录：/sys/block/<disk>/integrity/tag_size
日期：2008年6月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：每512字节数据完整标签可用空间的字节数。
What:/sys/block/<disk>/integrity/write_generate
Date:June 2008
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:Indicates whether the block layer should automatically generate checksums for write requests bound for devices that support receiving integrity metadata.
目录：/sys/block/<disk>/integrity/write_generate
日期：2008年6月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：表明块层是否应该为支持接收完整数据元的写请求约束设备自动生成校验。
What:/sys/block/<disk>/alignment_offset
Date:April 2009
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:Storage devices may report a physical block size that is bigger than the logical block size (for instance a drive with 4KB physical sectors exposing 512-byte logical blocks to the operating system). This parameter indicates how many bytes the beginning of the device is offset from the disk's natural alignment.
目录：/sys/block/<disk>/alignment_offset
日期：2009年4月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：存储设备可能会记录一个比逻辑块大小更大的物理块的大小（例如一个4KB物理扇区的驱动呈现给操作系统的是512B的逻辑块）。这个参数表示设备的开头离磁盘的自然对齐有多少字节的偏移。
What:/sys/block/<disk>/<partition>/alignment_offset
Date:April 2009
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:Storage devices may report a physical block size that is bigger than the logical block size (for instance a drive with 4KB physical sectors exposing 512-byte logical blocks to the operating system). This parameter indicates how many bytes the beginning of the partition is offset from the disk's natural alignment.
目录：/sys/block/<disk>/<partition>/alignment_offset
日期：2009年4月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：存储设备可能会记录一个比逻辑块大小更大的物理块的大小（例如一个4KB物理扇区的驱动呈现给操作系统的是512B的逻辑块）。这个参数表示分区的开头离磁盘的自然对齐有多少字节的偏移。
What:/sys/block/<disk>/queue/logical_block_size
Date:May 2009
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:This is the smallest unit the storage device can address. It is typically 512 bytes.
目录：/sys/block/<disk>/queue/logical_block_size
日期：2009年5月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：这是存储设备最小的可编址单元，通常为512字节。
What:/sys/block/<disk>/queue/physical_block_size
Date:May 2009
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:This is the smallest unit a physical storage device can write atomically. It is usually the same as the logical block size but may be bigger. One example is SATA drives with 4KB sectors that expose a 512-byte logical block size to the operating system. For stacked block devices the physical_block_size variable contains the maximum physical_block_size of the component devices.
目录：/sys/block/<disk>/queue/physical_block_size
日期：2009年5月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：这是一个物理存储设备可自动写入的最小单元，通常和逻辑块大小一样，也可能大一点。比如，4KB扇区的SATA驱动呈现给操作系统一个512B的物理块大小。对于堆块设备，物理块大小的变量包含了组件设备的最大物理块的大小。
What:/sys/block/<disk>/queue/minimum_io_size
Date:April 2009
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:Storage devices may report a granularity or preferred minimum I/O size which is the smallest request the device can perform without incurring a performance penalty. For disk drives this is often the physical block size. For RAID arrays it is often the stripe chunk size. A properly aligned multiple of minimum_io_size is the preferred request size for workloads where a high number of I/O operations is desired.
目录：/sys/block/<disk>/queue/minimum_io_size
日期：2009年4月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：存储设备可能会记录一个粒度或优先级最小的I/O的大小，这是在不导致性能降低的前提下，可执行设备的最小要求。对于磁盘设备，这通常是物理块大小。对于RAID阵列，这通常是条纹快大小。恰当的最小输入输出大小的多重对齐是需要大量I/O操作的工作负载的首选请求。
What:/sys/block/<disk>/queue/optimal_io_size
Date:April 2009
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:Storage devices may report an optimal I/O size, which is the device's preferred unit for sustained I/O. This is rarely reported for disk drives. For RAID arrays it is usually the stripe width or the internal track size. A properly aligned multiple of optimal_io_size is the preferred request size for workloads where sustained throughput is desired. If no optimal I/O size is reported this file contains 0.
目录：/sys/block/<disk>/queue/optimal_io_size
日期：2009年4月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：存储设备可能会记录一个最优I/O大小，这是持续的I/O首选单元。这很少为磁盘驱动记录。对于RAID阵列，这通常是条纹宽度或是内部跟踪大小。恰当的最优输入输出大小的多重对齐是需要持续吞吐量的工作负载的首选请求大小。如果没有记录最优I/O大小，这个文件置为0。
What:/sys/block/<disk>/queue/nomerges
Date:January 2010
Contact:
Description:Standard I/O elevator operations include attempts to merge contiguous I/Os. For known random I/O loads these attempts will always fail and result in extra cycles being spent in the kernel. This allows one to turn off this behavior on one of two ways: When set to 1, complex merge checks are disabled, but the simple one-shot merges with the previous I/O request are enabled. When set to 2,all merge tries are disabled. The default value is 0 which enables all types of merge tries.
目录：/sys/block/<disk>/queue/nomerges
日期：2010年1月
联系方式：
摘要：标准的I/O电梯运行包括尝试合并相邻I/O。对于已知的随机I/O负载，这些尝试通常会失败，并导致额外的周期用于内核。阻止这种行为的两种方式之一：当置为1时，复杂的合并检查被禁用，但是和前面的I/O请求的简单一次性合并被启用。当置为2时，所有的尝试合并都是被禁用的。合并默认值是0——所有类型的尝试合并都被启用。
What:/sys/block/<disk>/discard_alignment
Date:May 2011
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:Devices that support discard functionality may internally allocate space in units that are bigger than the exported logical block size. The discard_alignment parameter indicates how many bytes the beginning of the device is offset from the internal allocation unit's natural alignment.
目录：/sys/block/<disk>/discard_alignment
日期：2011年5月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：支持丢弃功能的设备可能在比导出的逻辑块大的单元内部分配空间。丢弃对齐参数表明设备的开头离内部分配单元的自然对齐的偏移量有多少字节。
What:/sys/block/<disk>/<partition>/discard_alignment
Date:May 2011
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:Devices that support discard functionality may internally allocate space in units that are bigger than the exported logical block size. The discard_alignment parameter indicates how many bytes the beginning of the partition is offset from the internal allocation unit's natural alignment.
目录：/sys/block/<disk>/<partition>/discard_alignment
日期：2011年5月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：支持丢弃功能的设备可能在比导出的逻辑块大的单元内部分配空间。丢弃对齐参数表明分区的开头离内部分配单元的自然对齐的偏移量有多少字节。
What:/sys/block/<disk>/queue/discard_granularity
Date:May 2011
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:Devices that support discard functionality may internally allocate space using units that are bigger than the logical block size. The discard_granularity parameter indicates the size of the internal allocation unit in bytes if reported by the device. Otherwise the discard_granularity will be set to match the device's physical block size. A discard_granularity of 0 means that the device does not support discard functionality.
目录：/sys/block/<disk>/queue/discard_granularity
日期：2011年5月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：支持丢弃功能的设备可能用比逻辑块大的单元在内部分配空间。如果被设备记录，丢弃粒度参数表明内部分配单元以比特位单位的大小。否则，丢弃粒度将会被设置成匹配设备物理块大小的值。丢弃粒度为0表明设备不支持丢弃功能。
What:/sys/block/<disk>/queue/discard_max_bytes
Date:May 2011
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:Devices that support discard functionality may have internal limits on the number of bytes that can be trimmed or unmapped in a single operation. Some storage protocols also have inherent limits on the number of blocks that can be described in a single command. The discard_max_bytes parameter is set by the device driver to the maximum number of bytes that can be discarded in a single operation. Discard requests issued to the device must not exceed this limit. A discard_max_bytes value of 0 means that the device does not support discard functionality.
目录：/sys/block/<disk>/queue/discard_max_bytes
日期：2011年5月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：支持丢弃功能的设备可能在单一操作上能够削减或映射的字节数有内部限制。一些存储协议对于单一命令中能被描述的块的数量也有固定的限制。丢弃最大字节参数被驱动设备设置成在单一操作中能够被丢弃的字节的最大数量。设备发出的丢弃请求不能超过这个限制。丢弃最大字节值为0表明该设备不支持丢弃功能。
What:/sys/block/<disk>/queue/discard_zeroes_data
Date:May 2011
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:Devices that support discard functionality may return stale or random data when a previously discarded block is read back. This can cause problems if the filesystem expects discarded blocks to be explicitly cleared. If a device reports that it deterministically returns zeroes when a discarded area is read the discard_zeroes_data parameter will be set to one. Otherwise it will be 0 and the result of reading a discarded area is undefined.
目录：/sys/block/<disk>/queue/discard_zeroes_data
日期：2011年5月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：支持丢弃功能的设备当之前丢弃的块被读回时，可能返回过期或随机数据。如果文件系统想要显式地丢弃块这样可能会导致问题发生。如果设备报告当丢弃区域被读设备肯定返回0，丢弃零数据参数将被置1。否则将被置为0，并且读丢弃区域的结果是未定义的。
What:/sys/block/<disk>/queue/write_same_max_bytes
Date:January 2012
Contact:Martin K. Petersen <martin.petersen@oracle.com>
Description:Some devices support a write same operation in which a single data block can be written to a range of several contiguous blocks on storage. This can be used to wipe areas on disk or to initialize drives in a RAID configuration. write_same_max_bytes indicates how many bytes can be written in a single write same command. If write_same_max_bytes is 0, write same is not supported by the device.
目录：/sys/block/<disk>/queue/write_same_max_bytes
日期： 2012年1月
联系方式：Martin K. Petersen <martin.petersen@oracle.com>
摘要：一些设备在单个数据块可以被写到几个相邻的数据块中的存储器中支持写相同操作。这个可以用来擦除磁盘区域，还可以在RAID配置中初始化驱动器。写相同最大字节表明在一次写相同命令中有多少字节可以被写入。如果写相同最大字节为0，则说明设备不支持写相同。
目录：/proc/diskstats
日期：February 2008
摘要：The /proc/diskstats file displays the I/O statistics of block devices. Each line contains the following 14 fields:
1 major number
2 minor mumber
3 device name
4 reads completed successfully
5 reads merged
6 sectors read
7 time spent reading (ms)
8 writes completed
9 writes merged
10 sectors written
11 time spent writing (ms)
12 I/Os currently in progress
13 time spent doing I/Os (ms)
14 weighted time spent doing I/Os (ms)
== ===================================
Kernel 4.18+ appends four more fields for discard tracking putting the total at 18:
15 discards completed successfully
16 discards merged
17 sectors discarded
18 time spent discarding
== ===================================
Kernel 5.5+ appends two more fields for flush requests:
19 flush requests completed successfully
20 time spent flushing
总结：
sysfs 文件系统对于 Linux 系统至关重要，因为它提供了与内核交互的接口，支持设备管理、调试和动态响应等关键功能节点。/sys 目录是一个重要的虚拟文件系统入口，用于与内核进行交互，并让用户空间（user space）程序能够访问和修改内核内部状态；/sys 目录是 sysfs 文件系统的挂载点。
/sys/devices
该目录是 Linux 系统中的一个虚拟文件系统的一部分，主要用于提供有关系统中物理设备的信息。是 sysfs 文件系统的核心组成部分，允许用户空间程序以一种结构化的方式与内核中的设备和驱动程序进行交互。
1. 结构
/sys/devices 目录的结构非常复杂，通常包含多个子目录和文件，主要可以分为以下几类：
物理设备：每个物理设备（如硬盘、USB 设备、网络接口等）都有一个对应的目录，目录名称通常是设备的唯一标识符（如设备 ID）。
子设备：某些设备可能具有多个子设备，例如，一个 USB 控制器可能连接多个 USB 设备。
类别：设备可能会被分类到不同的类别中，如 class、bus、platform 等。
2. 关键文件与信息
在 /sys/devices 中，提供了有关设备的状态和属性的信息，包括但不限于：
uevent：每个设备都有一个 uevent 文件，用于描述设备事件。当设备的状态发生变化时，相关的信息会写入这个文件，以通知用户空间的程序。
driver：指向该设备驱动程序的链接，显示当前处理该设备的驱动程序。
modalias：用于描述设备的模块别名，帮助内核确定应加载哪个驱动程序。
power：与设备的电源管理相关的文件夹，提供有关设备电源状态的信息，如开启、关闭、休眠等模式。
3. 设备类别
在 /sys/devices 下，设备可以按照不同的类别进行组织，常见的包括：
/sys/devices/pci0000:00/：表示 PCI 设备的层次结构，每个设备都有其特定的路径。
/sys/devices/platform/：表示平台设备，通常是集成在主板上的设备，如 GPIO 控制器。
/sys/devices/usb/...：专门用于 USB 设备的目录，显示所有连接的 USB 设备。
4. 与用户空间的交互
动态性：/sys/devices 是动态更新的，设备的添加和删除会自动反映在该目录中。例如，当插入 USB 设备时，相应的目录会被创建，而当设备被移除时，该目录会被删除。
交互：用户可以通过读取和写入 /sys/devices 中的文件来获取设备状态或配置设备属性。例如，可以通过修改 power 目录中的文件来控制设备的电源管理行为。
/sys/dev
该目录是 Linux 系统中 sysfs 文件系统的一部分，主要用于提供与设备相关的信息和接口。虽然在许多现代 Linux 系统中，设备信息通常位于 /sys/devices 中，但 /sys/dev 目录仍然存在并被用作一些特定设备的接口。
1. 设备分类/sys/dev
目录下的内容通常与设备的类型或类别相关，可能包含多个子目录，每个子目录对应一种设备类型。这些子目录中的文件和子目录提供了关于设备状态、驱动程序、模块和配置参数的信息。
2. 关键文件和信息
在 /sys/dev 目录下，有以下几类重要文件和信息：
uevent：每个设备都有一个 uevent 文件，用于描述设备事件。当设备状态发生变化时，相关的信息会写入这个文件，以通知用户空间的程序。
driver：指向处理该设备的驱动程序的链接。通过这个文件，可以知道哪个驱动正在管理特定设备。
power：与电源管理相关的文件夹，提供有关设备电源状态的信息，允许用户控制设备的电源模式（如开启、关闭、休眠等）。
modalias：描述设备的模块别名，帮助内核确定应加载哪个驱动程序。
3. 与设备的交互
动态性：/sys/dev 是动态更新的，设备的添加和删除会自动反映在该目录中。例如，当插入 USB 设备时，相应的目录会被创建，而当设备被移除时，该目录会被删除。
交互：可以通过读取和写入 /sys/dev 中的文件来获取设备状态或配置设备属性。例如，可以通过修改 power 目录中的文件来控制设备的电源管理行为。
4. 应用场景
调试：开发者可以查看 /sys/dev 中的设备信息，以帮助调试硬件问题或驱动程序问题。
设备管理：系统管理员可以使用 /sys/dev 提供的信息来进行设备监控和管理，例如检查设备是否正常工作或修改设备设置。
编写脚本：开发人员可以编写脚本，通过解析 /sys/dev 中的信息来自动化设备管理任务。
/sys/class
该目录下包含所有注册在kernel里面的设备类型，这是按照设备功能分类的设备模型，每个设备类型表达具有一种功能的设备。每个设备类型子目录下都是这种哦哦那个设备类型的各种具体设备的符号链接，这些链接指向/sys/devices/name下的具体设备。设备类型和设备并没有一一对应的关系，一个物理设备可能具备多种设备类型；一个设备类型只表达具有一种功能的设备，比如：系统所有输入设备都会出现在/sys/class/input之下，而不论它们是以何种总线连接到系统的(/sys/class也是构成linux统一设备模型的一部分)。
其主要用于提供对设备类的访问。这一目录结构允许用户空间程序以统一的方式与不同类型的设备进行交互。是设备类别的抽象表示，每个类别下包含了一组相似设备的接口。
1. 结构
在 /sys/class 中，设备被按照其功能或特性分类，每个子目录代表一个设备类别。例如常见的类别包括：
net：网络接口相关的设备。
tty：终端设备（如串口）。
block：块设备，如硬盘、USB 存储等。
power_supply：电源管理相关的设备，如电池信息。
每个类别下会包含对应设备的符号链接，这些链接指向 /sys/devices 目录中实际的设备实例。
2. 关键功能和内容
2.1 设备接口
在 /sys/class 目录中，每个子目录都包含了与该类别相关的设备的信息，通常会有以下几种重要的文件和符号链接：
符号链接：每个设备类别下的设备通常以符号链接的方式存在。例如，在 /sys/class/net/ 下，每个网络接口的名称（如 eth0 或 wlan0）都是指向 /sys/devices 中实际设备的链接。
属性文件：每个设备都有一些属性文件，通常包括：
uevent：描述设备事件的文件，用于通知用户空间程序设备状态变化。
device：指向设备本身的链接。
driver：指向处理该设备的驱动程序的链接。
power：与电源管理相关的文件夹，提供设备电源状态的信息。
2.2 统一接口
/sys/class 提供了一种统一的方式来访问和管理不同类型的设备。例如，你可以通过访问 /sys/class/net/ 来获取所有网络接口的信息，而不需要具体知道它们在 /sys/devices 中的物理位置。这种抽象使得设备管理变得更加简便和一致。
3. 动态性
/sys/class是动态更新的，设备的添加和删除会实时反映在该目录中。当新的设备被插入时，相应的类别下会创建新的目录和符号链接；当设备被移除时，它们会自动消失。这使得系统能够实时反映设备的状态变化。
4. 使用示例
以下是一些常见的使用场景和命令示例：
查看网络接口：
ls /sys/class/net/
这将列出所有网络接口，例如 eth0 和 wlan0。
获取设备信息：
cat /sys/class/net/eth0/address
这将显示指定网络接口的 MAC 地址。
控制设备：
可以通过写入特定的属性文件来控制设备，例如启用或禁用某个网络接口。
5. 应用场景
设备管理：系统管理员可以通过 /sys/class 获取设备状态和属性信息，以进行监控和管理。
自动化脚本：开发人员可以编写脚本，以读取 /sys/class 中的信息，并自动化设备管理任务。
系统调试：调试设备问题时，可以参考 /sys/class 中的信息，以快速定位问题根源。
注意事项：/sys/class 目录并不直接包含设备的物理信息，它只是对设备进行分类的逻辑表示。所有实际设备信息仍然存储在 /sys/devices 中。
/sys/class 目录为 Linux 系统中的设备管理提供了一个清晰而统一的接口，用户能够方便地访问和控制各种类型的设备。理解其的结构和功能对于系统开发、设备管理和故障排查等方面都是十分重要的。
/sys/block
该目录下的所有子目录代表着系统中当前被发现的所有块设备。按照功能来说防止在/sys/class下会更合适，但由于历史遗留因素而一直存在于/sys/block，但从linux2.6.22内核开始这部分就已经标记为过去时，只有打开了CONFIG_SYSFS_DEPRECATED配置编译才会有这个目录存在，并且其中的内容在从v2.6版本开始已经正式移到了/sys/class/block，旧的接口/sys/block为了向后兼容而保留存在，但其中的内容已经变为了指向它们在/sys/devices/中真实设备的符号链接文件。专门用于提供块设备（block devices）的信息和接口。块设备是可以随机访问的设备，通常用于存储数据，如硬盘、固态硬盘（SSD）、USB 驱动器等。
1. 结构
在 /sys/block 目录下，每个块设备都有一个以设备名称命名的子目录。常见的块设备可能包括：
sda：第一个 SATA 硬盘
sdb：第二个 SATA 硬盘
nvme0n1：第一个 NVMe SSD
每个设备目录中包含了一组文件和子目录，用于描述和管理该块设备。
2. 关键内容和功能
在 /sys/block 中，块设备的每个子目录通常会包含以下几个重要的文件和信息：
2.1 设备属性
size：设备的总大小，以 512 字节块为单位。用户可以通过读取这个文件来获取块设备的总容量。
ro：表示设备是否为只读，若为 1，则设备为只读；若为 0，则设备可读写。
device：指向实际设备的链接，通常指向 /sys/devices 中的相应设备目录。
uevent：用于描述设备事件的文件，当设备状态改变时，可以通过这个文件通知用户空间的程序。
queue：包含与设备 I/O 队列相关的设置和参数，例如调度策略和队列长度。
2.2 I/O 调度
在每个块设备的 /sys/block/<device>/queue 目录下，可以找到与 I/O 调度相关的文件，这些文件允许用户控制和优化设备的 I/O 行为。关键文件包括：
scheduler：当前使用的 I/O 调度器，可以通过写入不同的调度器名称来更改。例如，常见的调度器包括 cfq、deadline、noop。
max_sectors_kb：指定每次 I/O 操作的最大扇区数，通常用于优化性能。
discard_max_bytes：支持 TRIM 操作的块设备的最大字节数，用于 SSD 的垃圾回收。
3. 动态性
/sys/block目录是动态更新的，块设备的添加和删除会实时反映在该目录中。当新设备被连接到系统时，相应的块设备目录会被创建，而当设备被移除时，该目录会被删除。这使得系统能够实时反映设备的状态变化。
4. 使用示例
以下是一些常见的使用场景和命令示例：
查看块设备信息：
ls /sys/block/
这将列出所有块设备，例如 sda、sdb 等。
获取设备大小：
cat /sys/block/sda/size
这将显示 sda 设备的总大小（以 512 字节块为单位）。
检查设备只读状态：
cat /sys/block/sda/ro
这将返回 0 或 1，指示 sda 是否为只读。
更改 I/O 调度器：
echo deadline > /sys/block/sda/queue/scheduler
这将把 sda 设备的 I/O 调度器更改为 deadline。
5. 应用场景
设备监控：系统管理员可以通过 /sys/block 获取块设备的状态和属性信息，以进行监控和管理。
性能优化：开发人员可以调整 I/O 调度器和其他参数，以优化块设备的性能。
故障排查：在调试块设备问题时，可以参考 /sys/block 中的信息，以帮助定位问题。
注意事项：/sys/block 目录只包含块设备的逻辑视图，实际设备信息仍然存储在 /sys/devices 中。
该目录为 Linux 系统中的块设备管理提供了一个清晰而统一的接口，使用户能够方便地访问和控制各种块设备。理解 /sys/block 的结构和功能对于系统开发、设备管理和故障排查等方面都是十分重要的。
/sys/bus
该目录下的每个子目录都是kernel支持并且已经注册了的总线类型。这是内核设备按照总线类型分层放置的目录结构，其中的所有设备都是连接于某种总线之下的，bus子目录下的每种具体总线之下可以找到每个具体设备的符号链接，一般来说每个子目录(总线类型)下包含两个子目录，一个是devices，另一个是drivers；其中devices下是这个总线类型下的所有设备，这些设备都是符号链接，它们分别指向真正的设备(/sys/devices/name/下)；而drivers下是所有注册在这个总线上的驱动，每个driver子目录下是一些可以观察和修改的driver参数。主要用于设备模型和设备驱动的管理，通过文件系统接口向用户空间暴露内核对象（如设备、驱动程序等）的信息。
/sys/bus 目录下包含了与系统中各种总线相关的信息和接口，主要包括以下几个子目录：
1. subsystem: 该目录包含各类总线的子系统，例如 PCI、USB、I2C 等。在这些子目录中，可以找到与特定总线相关的设备和驱动程序的信息。
2. <bus_name>: 每个总线类型在此目录下都有一个相应的子目录。例如：
/sys/bus/pci：与 PCI 总线相关的信息。
/sys/bus/usb：与 USB 总线相关的信息。
/sys/bus/i2c：与 I2C 总线相关的信息。
总线类型示例
1、PCI 总线 (/sys/bus/pci):
该目录下包含了与 PCI 设备相关的信息。你可以找到每个 PCI 设备的详细信息，包括设备 ID、厂商 ID、状态等。
例如，使用 ls /sys/bus/pci/devices/ 可以列出所有 PCI 设备。
2、USB 总线 (/sys/bus/usb):
包含了 USB 设备的信息。你可以查看已连接 USB 设备的详细信息。
文件如 devices/ 下会列出 USB 设备，drivers/ 下会列出相关 USB 驱动程序。
3、I2C 总线 (/sys/bus/i2c):
包括与 I2C 设备相关的信息，显示 I2C 设备的地址、类型等。
关键文件
每个总线目录下通常包含以下关键文件和目录：
devices/: 列出了该总线上连接的所有设备，每个设备都有一个对应的目录，里面包含该设备的属性文件。
drivers/: 列出了可以与该总线上的设备交互的所有驱动程序。
bind/unbind: 这两个文件用于将设备绑定到驱动程序或将其解绑。通过写入设备的名称或 ID，可以手动进行绑定或解绑操作。
uevent: 该文件用于生成 uevent，通常用于设备热插拔事件的通知。
使用示例
1. 查看 PCI 设备:
ls /sys/bus/pci/devices/
2. 查看 USB 设备信息:
ls /sys/bus/usb/devices/
3. 绑定设备到驱动:
echo "<device_id>" > /sys/bus/pci/drivers/<driver_name>/bind
4. 解绑设备:
echo "<device_id>" > /sys/bus/pci/drivers/<driver_name>/unbind
/sys/bus目录是 Linux 内核中处理设备和驱动的重要组成部分，它通过 sysfs 提供了一个统一的接口，让用户能够以文件系统的方式访问和管理系统中的设备。用户可以通过这个目录，可以获得系统设备的详细信息，并对设备进行管理和控制。在设备驱动开发和系统调试中，这个目录提供了很大的帮助。
/sys/fs
该目录使用来描述系统中所有的文件系统，包括文件系统本身和按照文件系统分类存放的已挂载点。主要用于管理和提供文件系统相关的信息和接口。目录下包含了与不同类型的文件系统相关的子目录和信息，允许用户以文件系统的方式访问内核内部的数据结构和状态。
在 /sys/fs 目录下通常会看到一些关于文件系统的子目录。其中最常用的包括：
1. /sys/fs/fscache:
这个目录与文件系统缓存（fscache）相关，用于管理和提供有关文件系统缓存的信息。它包含了缓存对象的状态以及所使用的缓存策略的信息。可以通过这个目录监控哪些文件系统正在使用缓存，以及缓存的使用情况。
2. /sys/fs/cgroup:
cgroup（控制组）是 Linux 内核的一种功能，用于限制、记录、隔离进程组的资源使用（如 CPU、内存等）。
/sys/fs/cgroup 目录用于管理控制组及其层次结构。在这里可以找到关于各个 cgroup 的子系统的信息，并能对 cgroup 进行创建、删除和配置。
3. /sys/fs/selinux:
该目录用于与 SELinux（安全增强型 Linux）相关的信息和配置。SELinux 是一种强制访问控制（MAC）机制，提供了更细粒度的权限控制。/sys/fs/selinux 中包含了 SELinux 的状态信息、策略和上下文等。
4. /sys/fs/ext4 (或其他文件系统类型):
如果系统中挂载了 ext4 文件系统，可能会看到一个名为 /sys/fs/ext4 的目录。这个目录提供了与 ext4 文件系统相关的特定信息，例如挂载选项、日志状态等。
关键功能和文件
每个子目录中通常包含以下关键文件和信息：
状态信息: 各个目录通常会有状态信息文件，显示当前的配置和状态。
控制文件: 用于调整或配置相应的功能。例如，在 /sys/fs/cgroup 中，可以通过写入特定值来设置资源限制。
属性文件: 包含有关特定文件系统的详细属性，如大小、类型、使用情况等。
使用示例
1. 查看 cgroup 信息:
ls /sys/fs/cgroup/
2. 查看 SELinux 状态:
cat /sys/fs/selinux/enforce
3. 查看 fscache 状态:
ls /sys/fs/fscache/
在 Linux 中 /sys/fs 目录的地位其实非常重要，它为文件系统和各种管理功能，提供了一套统一、规范的访问接口。不管是普通用户还是管理员，都能通过它方便地查看、控制文件系统的状态、性能和相关配置。所以不管是日常运维、问题调试，还是做底层开发，搞懂其中的内容和用途是特别关键。
/sys/kernel
这个目录下存放的是内核中所有可调整的参数。其把内核的运行状态、各类配置参数，通过文件系统的形式开放给用户空间。不管是系统管理员还是内核开发者，都能通过这个目录方便地查看和内核行为、调试信息、性能监控相关的内容。
该目录通常包含以下几个重要的子目录和文件：
1. /sys/kernel/hostname ：系统主机名（最常用）
作用：实时查看 / 临时修改当前系统主机名
类型：可读可写
查看：cat /sys/kernel/hostname
临时修改：echo "new-hostname" > /sys/kernel/hostname
对比和 hostname 命令等价，本质就是读写这个文件。
2. /sys/kernel/printk 内核日志输出级别（排错神器）
控制内核日志（dmesg）的输出级别，决定哪些内核信息会打印到控制台、日志文件。
文件包含 4 个数字（以空格分隔）：
控制台日志级别 | 默认消息级别 | 最低控制台级别 | 引导时默认级别
常用操作（临时调高日志，方便排错）：
# 查看当前级别
cat /sys/kernel/printk
# 临时打开全部内核日志（调试用）
echo "8 8 8 8" > /sys/kernel/printk
场景：驱动加载异常、内核报错、启动问题排查必备。
3. /sys/kernel/mm/ 内存管理子系统（性能调优核心）
mm = Memory Management，内存管理的全部可调参数都在这里，是服务器性能优化高频目录。
常用子项：
/sys/kernel/mm/transparent_hugepage/：透明大页 THP（影响 Redis/MySQL/Nginx 性能）
/sys/kernel/mm/min_free_kbytes：系统保留最小空闲内存（防 OOM、防业务卡顿）
/sys/kernel/mm/oom_kill_allocating_task：OOM 时杀死分配内存的进程（快速定位内存溢出）
/sys/kernel/mm/page_size：系统默认页大小（通常 4KB）
示例（查看透明大页状态）：
mount -t debugfs none /sys/kernel/debug
4. /sys/kernel/debug/ 内核调试文件系统（debug 专用）
作用：内核开发者 / 高级排错用，挂载后暴露内核内部数据结构、锁状态、栈跟踪、驱动状态
默认不一定挂载，手动挂载：
mount -t debugfs none /sys/kernel/debug
场景：驱动崩溃、内核死锁、性能 profiling（perf 配合使用）
注意：生产环境默认不建议常开，有安全与性能开销。
5. /sys/kernel/sched/ CPU 调度器配置（高并发优化）
控制 Linux 进程 / 线程调度策略，对高并发、低延迟服务（网关、数据库、消息队列）至关重要。
常用：
/sys/kernel/sched/wakeup_granularity_ns：唤醒粒度（影响调度延迟）
/sys/kernel/sched/min_granularity_ns：最小调度粒度
/sys/kernel/sched/rt_*：实时进程调度相关
6. /sys/kernel/security/ 安全相关（SELinux/AppArmor/LSM）
内核安全模块接口：
/sys/kernel/security/selinux/：SELinux 状态与配置
/sys/kernel/security/apparmor/：AppArmor 安全策略
查看 SELinux 状态：
cat /sys/kernel/security/selinux/enforce
7. /sys/kernel/power/ 电源管理（笔记本 / 嵌入式常用）
控制休眠、待机、电源状态：
/sys/kernel/power/state：设置休眠状态（disk/mem/off）
/sys/kernel/power/suspend_time：睡眠相关计时
服务器一般很少动，嵌入式 / 桌面常用。
8. /sys/kernel/cgroup/ 控制组（容器 / 云原生核心）
cgroup v1/v2 接口，Docker/K8s 资源限制（CPU / 内存 / IO）的底层实现就在此处。
容器的 CPU 限额、内存限流、POD 隔离，本质都是读写 /sys/kernel/cgroup 下的文件。
9. 其他文件
/sys/kernel/osrelease：内核版本（同 uname -r）
/sys/kernel/version：内核编译版本信息
/sys/kernel/modprobe：模块加载相关
/sys/kernel/uevent：硬件热插拔事件（内核与 udev 通信）
关键文件和功能
状态信息: 每个子目录通常包含许多状态信息文件，这些文件显示内核当前的配置和状态。例如，在 /sys/kernel/debug 下，你可以找到特定硬件的调试信息。
控制文件: 文件如 /sys/kernel/printk 提供了控制内核日志行为的接口。这使得在调试时可以灵活地调整信息的详细程度。
调试信息: /sys/kernel/debug 是进行内核调试的重要位置，尤其对开发者和系统管理员来说，能够帮助定位问题和分析性能。
实际应用
1. 内核调试:
开发驱动程序时，可以利用 /sys/kernel/debug 中的信息来检查驱动是否正常工作。使用 ftrace 进行函数跟踪，以优化性能。
2. 性能监控:
通过 /sys/kernel/perf 跟踪性能计数器，分析 CPU 的使用情况。在高负荷情况下，可以监控内存分配情况，确保没有出现内存泄漏。
3. 系统配置:
修改 /sys/kernel/printk 的设置，可以帮助识别在启动过程中遇到的问题，特别是在引导失败时。
/sys/kernel 是 Linux 内核非常关键的一个目录，它直接向外部提供了一套查看和管理内核运行状态的文件接口。借助目录里的各类信息可以很方便地监控系统性能、排查内核问题，甚至调整内核的运行行为。不管是日常运维、内核开发还是故障定位，搞懂其结构和用途，都特别重要。
/sys/firmware
该目录下包含对固件对象(firmware object)和属性进行操作和观察的接口，即这里是系统加载固件机制的对用户空间的接口。是查看和管理固件信息的关键入口。像 UEFI、设备树（Device Tree）这类固件相关内容，都能在这个目录下找到。它对我们管理系统启动、排查和调试固件问题有很大帮助。
以下是 /sys/firmware 目录中常见的子目录和文件的详细介绍：
1. /sys/firmware/efi
描述: 这个目录包含与 UEFI 固件相关的信息。UEFI 是现代计算机的固件接口，取代了传统的 BIOS。
常用文件 / 子目录：
/sys/firmware/efi/systab：UEFI 系统表地址，内核用于和 UEFI 交互。
/sys/firmware/efi/efivars/：UEFI 变量存储目录（最重要）。存放启动项、安全启动、固件参数等 UEFI 变量，efibootmgr 命令就是读写这个目录。
/sys/firmware/efi/config_table：UEFI 配置表信息。
使用示例:
# 查看是否为 UEFI 启动（有目录则是）
ls /sys/firmware/efi
# 查看 UEFI 变量
ls /sys/firmware/efi/efivars/
2. /sys/firmware/devicetree
描述: 此目录包含设备树（Device Tree）相关的信息。设备树是一种数据结构，用于描述硬件设备的配置，特别是在嵌入式系统中。
核心目录：
/sys/firmware/devicetree/base/：设备树根节点，包含所有硬件描述。
model：设备型号（如树莓派 4B）。
compatible：设备兼容属性。
serial-number：设备序列号。
子节点：cpu、memory、uart、gpio 等硬件信息。
使用示例:
# 查看设备型号
cat /sys/firmware/devicetree/base/model
# 查看内存配置
ls /sys/firmware/devicetree/base/memory
3. /sys/firmware/acpi
描述: 该目录包含与 ACPI（高级配置和电源接口）相关的信息。ACPI 是一种用于电源管理和硬件配置的标准。
常用内容：
/sys/firmware/acpi/tables/：存放系统所有 ACPI 表（DSDT、SSDT 等），硬件兼容性调试必备。
/sys/firmware/acpi/interrupts/：ACPI 中断信息。
/sys/firmware/acpi/power_resource/：电源资源管理。
作用：排查服务器无法休眠、电源管理异常、硬件识别失败时，必查这个目录。
使用示例:
ls /sys/firmware/acpi/
cat /sys/firmware/acpi/tables/* # 查看所有 ACPI 表
4. /sys/firmware/dmi（硬件信息，x86 桌面 / 服务器）
DMI（桌面管理接口）是固件记录硬件出厂信息的模块，常用的 dmidecode 命令就是读取这个目录的数据。
存放信息：主板型号、厂商、序列号、BIOS 版本、发布日期、处理器、内存、机箱信息
常用文件：
/sys/firmware/dmi/tables/smbios_entry_point：SMBIOS 入口点。
/sys/firmware/dmi/entries/：按类型分类的 DMI 条目。
作用：无需安装工具，直接读取硬件出厂信息，适合自动化脚本。
5. 其他常见子目录
/sys/firmware/meminit：内核启动时内存初始化相关信息。
/sys/firmware/qemu_fw_cfg：QEMU 虚拟机固件配置接口，虚拟机专用。
/sys/firmware/opal：IBM Power 平台专用固件接口。
功能和用途
1. 固件变量管理:
通过 /sys/firmware/efi/efivars 目录，可以管理 EFI 变量，这对于定制系统启动过程、配置安全启动等非常重要。
2. 设备树支持:
在嵌入式系统中，设备树提供了一种描述和配置硬件的平台无关的方法，使得 Linux 内核能够更灵活地支持多种硬件。
3. 电源管理:
ACPI 相关的信息可以帮助系统管理员和开发者优化电源使用，监控系统的电源状态，确保高效的电源管理。
4. 调试和故障排查:
可以通过查看固件和设备树信息来调试硬件问题、启动失败等故障，为开发和维护提供支持。
实际应用
1. 修改启动选项:
使用 efivars 目录中的变量，可以改变系统的启动顺序或启用/禁用安全启动等功能。
2. 检查硬件配置:
通过设备树信息，可以确认系统是否正确识别了所有硬件组件，并且能够配置它们。
3. ACPI 监控:
监控 ACPI 表和状态，可以帮助管理员了解系统的电源使用情况，并进行相应的优化。
注意事项
1、绝大多数文件只读，不要强行修改
固件信息固化在硬件 / 固件中，修改 /sys/firmware 不会改变底层配置，还可能导致内核异常。
2、平台不同，内容差异极大
不要在 x86 机器找 devicetree，也不要在 ARM 板卡找 efi。
3、排查启动 / 硬件问题的关键目录
开机异常、电源管理失效、硬件识别失败，优先查看 /sys/firmware 下的日志和表信息。
4、普通用户可查看，无需 root
该目录默认开放读权限，普通用户也能查看信息且无需 sudo。
/sys/hypervisor
该目录是与开源虚拟机监视器虚拟化Xen相关的装置。用于访问 Linux 中的虚拟化与 Hypervisor 信息，仅在支持虚拟化的内核中存在，助于快速获取 KVM、Xen、VMware 等虚拟化环境的详细状态与配置。
hypervisor 目录通常包含以下几个子目录和文件：
1. /sys/hypervisor/type
描述: 这个文件指示当前正在使用的虚拟化技术类型，例如 kvm、xen、vmware 等。
内容: 文件内容是一个字符串，表明当前系统使用的程序类型。
使用示例:cat /sys/hypervisor/type
2. /sys/hypervisor/version
描述: 该文件包含当前虚拟化环境的版本信息。
内容: 通常是一个字符串，表示版本号。
使用示例:cat /sys/hypervisor/version
3. /sys/hypervisor/uuid
描述: 这个文件存储当前虚拟机监视器的唯一标识符（UUID）。
内容: UUID 是一个唯一的字符串，用于标识特定的虚拟化环境实例。
使用示例:cat /sys/hypervisor/uuid
4. /sys/hypervisor/identification/
描述：该文件通常包含虚拟化环境的相关识别信息，如供应商名称、版本、特定配置选项等。这些信息有助于用户理解当前正在运行的虚拟化平台的具体实现及其特性。
使用示例：
# 查看厂商和产品名称
cat /sys/hypervisor/identification/vendor
cat /sys/hypervisor/identification/product_name
功能和用途
1. 识别虚拟化类型:
通过检查 /sys/hypervisor/type 文件，系统管理员和开发者可以快速确认正在使用的虚拟化平台。这在进行系统调试和优化时非常有用。
2. 版本管理:
/sys/hypervisor/version 文件可以帮助用户了解当前虚拟化环境的版本，以便于进行更新和维护。确保使用最新的稳定版本可以提高安全性和性能。
3. 唯一标识:
UUID 提供了一种可靠的方式来标识特定的虚拟化环境，这在管理多个虚拟机或在云环境中部署时尤其重要。通过 UUID可以跟踪和管理不同的虚拟机实例。
实际应用
1. 虚拟化监控:
管理员可以使用这些信息来监控和管理其虚拟化环境，确保所有组件正常运行。
2. 故障排除:
在出现问题时，了解虚拟化类型和版本可以帮助快速定位故障原因，并寻找解决方案。
3. 系统配置:
在配置和调整虚拟机设置时，了解当前运行的超管程序类型可以指导用户选择合适的配置选项。
/sys/module
该目录下有系统中所有的模块信息，不论这些模块是以内联(inlined)方式编译到内核映像文件中还是编译为外模块(.ko文件)，都可能出现在/sys/module中。即module目录下包含了所有的被载入kernel的模块。它提供了关于内核模块的信息，内核模块是可加载的代码段，允许动态扩展内核功能而无需重新编译或重启系统。通过 /sys/module 目录，用户和开发者可以查看和管理当前加载的内核模块及其相关信息。
该目录包含以已加载模块名称命名的子目录，每个子目录都代表一个内核模块，并包含该模块的相关信息。这些子目录通常包括以下几个文件和子目录：
1. 模块名称子目录
每个已加载的内核模块都有一个对应的目录，名称与模块相同。如果加载了名为 kvm 的模块，那么将有一个 /sys/module/kvm 目录。
2. /sys/module/<module_name>/parameters
描述: 这个目录包含模块参数的信息。某些模块在加载时可以接受参数以修改其行为。
内容: 每个参数通常是一个文件，文件名为参数名称，文件内容表示当前参数值。
使用示例:cat /sys/module/<module_name>/parameters/<parameter_name>
3. /sys/module/<module_name>/taint
描述: 此文件指示内核模块是否导致内核进入“污染”状态。污染状态通常表明内核正在运行非开源或不受支持的代码。
内容: 通常是一个数字，表示污染类型。
4. /sys/module/<module_name>/initstate
描述: 此文件指示模块的初始化状态。
内容: 内容可能是 live、unloading 或 dead，分别表示模块处于活动、卸载或未加载状态。
5. /sys/module/<module_name>/refcnt
描述: 表示当前引用计数，即有多少个进程或其他模块正在使用该模块。
内容: 一个整数值，指示引用计数。
功能和用途
1. 查看已加载模块:
通过检查 `/sys/module` 目录，用户可以快速查看所有已加载的内核模块，了解系统的当前状态。
2. 管理模块参数:
用户可以访问模块参数以调整模块行为。通过修改这些参数，可以优化性能或启用/禁用特定功能。
3. 调试和故障排除:
在进行系统调试时，查看模块的状态、引用计数和污染状态可以帮助定位问题。
4. 开发和测试:
开发人员可以利用此目录中的信息来测试和验证新开发的内核模块，确保它们正确加载并按预期工作。
实际应用
1. 动态模块管理:
使用 modprobe、insmod 和 rmmod 命令管理模块时，可以通过 /sys/module 验证模块的加载和状态。
2. 性能调优:
通过调整模块参数，如网络驱动程序的缓冲区大小，可以提高系统性能。
3. 安全审计:
检查模块的污染状态可以帮助管理员识别潜在的安全风险，确保系统运行在安全的内核环境中。
/sys/power
该目录是系统中的电源选项，对正在使用的power子系统的描述。这个目录下有几个属性文件可以用于控制整个机器的电源状态，如可以向其中写入控制命令让机器关机/重启等等。是 Linux 系统中用于管理电源管理相关功能的一个重要部分。它提供了一个接口来控制和查询系统的电源状态、睡眠模式和其他电源管理特性。通过这个目录，用户和开发者可以对系统进行电源管理，优化能耗，特别是在笔记本电脑和移动设备上。
目录结构
/sys/power 目录通常包含以下几个文件和子目录：
1. sleep
描述:此文件用于控制系统的休眠（sleep）行为。
内容:可以写入特定的命令来使系统进入不同的休眠状态，例如 disk（将系统写入磁盘休眠）、mem（进入内存休眠）。
使用示例:echo 'disk' > /sys/power/sleep
2. state
描述:此文件提供当前电源状态的信息。
内容:包含系统的当前电源状态，如 active、suspend 等。
使用示例:cat /sys/power/state
3. wantrun
描述: 此文件用于指示是否有待处理的进程希望系统保持活动状态。
内容: 该文件通常会被进程写入特定值，以请求系统不进入低功耗状态。
使用示例:echo '0' > /sys/power/wantrun # 请求系统可以进入低功耗状态
4. pm_test
描述: 这个文件用于测试电源管理功能，而不实际进入低功耗状态。
内容: 允许用户进行测试，比如设置为 platform（测试平台电源管理），而不改变当前状态。
使用示例:echo 'platform' > /sys/power/pm_test
5. sleep_stats
描述: 这个文件记录有关系统进入和退出睡眠状态的统计信息。
内容: 包含有关系统休眠次数和持续时间的详细信息，可用于监控和优化电源管理。
使用示例:cat /sys/power/sleep_stats
关键功能和用途
1. 电源管理控制:
通过 /sys/power 目录中的文件，用户可以直接控制系统的电源管理行为，例如进入休眠模式或获取电源状态。
2. 优化能耗:
了解和调整系统的电源状态可以帮助用户在移动设备上延长电池寿命，减少能耗。
3. 故障排除:
监控休眠状态和统计信息有助于识别电源管理问题，确保系统能够有效地进入和退出休眠模式。
4. 调试和开发:
开发人员可以利用这些接口来测试新电源管理功能或调试现有的电源管理实现。
实际应用
1. 休眠功能:
在笔记本电脑上，用户可以通过 /sys/power/sleep 文件控制何时进入休眠状态，从而节省电池电量。
2. 系统监控:
系统管理员可以定期检查 /sys/power/sleep_stats 来获取系统的电源管理性能数据，以便进行优化。
3. 测试新特性:
在开发新的电源管理驱动程序时，可以使用 /sys/power/pm_test 文件进行实验，而不影响生产环境。
本文部分参考自互联网，感谢原作者及译者。