我们来深入、系统地学习Linux内核中三个非常重要但又常常被混淆的虚拟文件系统：'procfs', 'sysfs', 和 'debugfs'。
核心思想：一切皆文件 (Everything is a File)
在深入之前，必须理解Linux/Unix的核心设计哲学：“一切皆文件”。这不仅仅指磁盘上的常规文件，也包括设备、网络套接字，以及我们今天要讨论的——内核数据结构。
'procfs', 'sysfs', 'debugfs'都不是存储在硬盘上的真实文件系统。它们是伪文件系统 (Pseudo-filesystem)或 虚拟文件系统 (Virtual filesystem)。当你读写这些文件系统中的文件时，你实际上是在直接与Linux内核进行交互。内核会将内部的数据、状态和可调参数“伪装”成文件和目录的形式，让你能用标准的文件操作命令（如ls, cat, echo）来查看和修改它们。
这是一种极其强大和优雅的设计，为用户空间提供了一个统一的、可编程的接口来窥探和控制内核。
快速对比
特性 | procfs (/proc) | sysfs (/sys) | debugfs (/debug) |
核心目的 | 进程信息和 混杂的内核信息 | 系统设备和驱动模型 | 内核调试 |
数据模型 | 混杂，部分结构化（PID目录），部分非结构化 | 严格的层次化对象模型 (kobject) | 无规则，完全由开发者决定 |
API稳定性 | 部分稳定，但不推荐用于新接口 | 稳定，被视为用户空间的ABI | 极不稳定，绝不能依赖 |
设计规则 | 一个文件可包含多种信息 | 一个文件只包含一个值 | 无规则，一个文件可包含大量调试信息 |
主要用户 | 系统管理员、用户、历史遗留脚本 | udev、系统管理工具、用户 | 内核开发者 |
第一部分：procfs- 进程信息与历史遗留的“杂物间”
procfs是这三者中历史最悠久的。它的初衷非常明确：为每个正在运行的进程提供一个目录，里面包含了该进程的所有信息。
挂载点：/proc
1. 核心功能：进程信息
这是procfs最核心、最结构化的部分。系统中的每一个进程（Process）都有一个以其进程ID (PID)命名的目录/proc/<PID>。
实战示例：假设我们有一个PID为1234的进程。
查看进程状态：
你会看到非常详细的信息，如进程名（Name）、状态（State，如Sleeping, Running）、内存使用（VmRSS, VmSize）等。
查看进程启动命令：
这会显示启动该进程的完整命令行，参数之间用空字符\0分隔。
查看进程打开的文件描述符：
你会看到0 (标准输入), 1 (标准输出), 2 (标准错误) 以及其他该进程打开的文件或socket的链接。
2. 扩展功能：混杂的内核信息
随着时间推移，'procfs'成为了一个方便的“出口”，内核开发者把各种非进程相关的系统信息和可调参数也放了进来。这使得/proc变得有些混乱，像一个“杂物间”。
实战示例：
# 查看当前值cat /proc/sys/net/ipv4/ip_forward# 临时修改值echo 1 > /proc/sys/net/ipv4/ip_forward
（sysctl命令是操作/proc/sys目录的更友好的封装）
总结：'procfs'主要用于获取进程信息和调整一些历史遗留的内核参数。由于其内容混杂且部分文件格式不统一，新的内核接口已不再推荐使用'procfs'。
第二部分：sysfs- 现代、整洁的设备模型视图
为了解决'procfs'的混乱，内核开发者设计了'sysfs'。它的目的非常纯粹：将内核的设备模型以一个严格的、层次化的目录结构暴露给用户空间。
挂载点：/sys
1. 核心原理：kobject 和层次结构
'sysfs'的结构直接映射了内核内部的kobject (kernel object)层次结构。你可以认为内核中每一个被管理的对象（如一个总线、一个设备、一个驱动）都是一个kobject。这些kobject之间存在父子关系，构成了设备树。'sysfs'就是这棵树在文件系统中的一个直观展现。
2. 目录结构
/sys下的顶级目录非常有条理：
/sys/devices/：这是物理设备树的核心视图，所有设备都按其在物理总线上的连接关系组织。这是sysfs的“实体”所在。
/sys/bus/：按总线类型（如pci, usb, i2c）组织设备。
/sys/class/：按设备类别（如net, input, leds）组织设备。这是用户最常交互的视图。
/sys/block/：所有块设备（如硬盘、SSD）的视图。
/sys/kernel/：内核本身的一些对象和可调参数。
bus, class, block目录下的内容大多是符号链接 (symlink)，它们都指向/sys/devices/下的真实设备目录。这提供了从不同角度查找和访问同一个设备的多种方式。
3. 实战示例
# 找到背光设备
ls /sys/class/backlight/# 假设设备是 intel_backlight# 查看最大亮度cat /sys/class/backlight/intel_backlight/max_brightness# 查看当前亮度cat /sys/class/backlight/intel_backlight/actual_brightness# 设置亮度 (需要root权限)echo 500 > /sys/class/backlight/intel_backlight/brightness
# /sys/class/net/eth0 是一个符号链接ls -l /sys/class/net/eth0# 查看MAC地址cat /sys/class/net/eth0/address# 查看网卡速度cat /sys/class/net/eth0/speed
总结：'sysfs'是一个结构化、稳定且面向设备的接口。它是现代Linux系统中'udev'等工具工作的基础。当你需要以编程方式获取设备信息或控制设备状态时，'sysfs'是首选。
第三部分：debugfs- 内核开发者的“草稿纸”
debugfs的名字已经说明了一切。它的唯一目的就是帮助内核开发者进行调试。
挂载点：通常是/sys/kernel/debug，但可能需要手动挂载：mount -t debugfs none /sys/kernel/debug
1. 核心特点：无规则就是它的规则
极不稳定：debugfs中的任何文件、目录或格式都不被视为稳定的API。它们可以在任何内核版本之间随意添加、删除或修改，恕不另行通知。因此，任何发行版中的程序或脚本都不应该依赖debugfs的任何内容。
完全自由：内核开发者可以在他们的驱动中非常方便地创建debugfs文件，用来转储内部状态、数据结构、性能计数器等任何有助于调试的信息。
格式自由：文件内容可以是简单的数字，也可以是格式混乱的大段文本。
2. 实战示例
debugfs的内容完全取决于你加载了哪些驱动以及这些驱动暴露了什么。
cat /sys/kernel/debug/usb/devices
这会打印出非常详细、原始的USB设备描述符和配置信息，比'lsusb'更底层。
查看显卡驱动内部状态(以Intel i915驱动为例)：
# 查看GPU频率cat /sys/kernel/debug/dri/0/i915_gpu_freq# 查看内存对象cat /sys/kernel/debug/dri/0/i915_gem_objects
这些文件的内容对于普通用户来说几乎是天书，但对于驱动开发者来说却是诊断问题的宝贵信息。
总结：'debugfs'是一个纯粹的、不稳定的调试工具。除非你正在开发或调试Linux内核/驱动，否则你几乎不需要接触它。如果你发现某个问题的解决方案建议你从'debugfs'中读取信息，要明白这是一种临时的诊断手段，而不是一个可以依赖的编程接口。
最终总结：如何选择？
想查看进程信息？ -> /proc/<PID>/
想查看系统硬件信息、设备状态，或者以脚本控制设备？ -> /sys/
想调整内核参数？ -> 优先看/sys/是否有对应接口。如果没有，再去看/proc/sys/ (并使用 'sysctl'命令)。
你正在写一个内核驱动，需要一个地方临时输出一些调试状态？ -> 'debugfs'是你的朋友。
你是一个普通用户或应用开发者，想依赖某个接口来获取信息？ -> 绝对不要碰 'debugfs'。优先使用 'sysfs'，其次是 'procfs'中那些公认稳定的部分(如/proc/meminfo)。
