写 sysfs 的文章之前先让我吐槽一句网上讲 sysfs 的资料大多抄内核文档读起来像在念天书。今天我不打算重复那套话我直接用实际干活儿的方式把这玩意儿掰开揉碎讲清楚重点放在“它为什么长这样”“你凭什么能通过 cat 和 echo 改内核状态”以及“怎么自己写一个设备属性文件”上。如果你写过内核驱动或者在嵌入式板子上调过硬件看完应该会有一种“原来如此”的感觉。1. sysfs究竟是个什么“文件系统”1.1 虚拟的、活的目录树sysfs 是 Linux 2.6 引入的一个虚拟文件系统默认挂在/sys目录下。它不占用任何磁盘空间所有文件背后都是一段内核代码在随时生成数据。你可以把/sys里的每个目录想象成内核设备模型中的“一个对象”每个文件想象成这个对象的“一个属性”。这句话听起来简单但很多人没真正理解它的分量。平时我们在/dev下看到的设备节点只是为了满足 open/read/write 这套 POSIX 接口而存在的“门把手”而在/sys下看到的目录和文件则是内核把自身的对象层级、设备拓扑、驱动绑定关系、资源分配情况原原本本地暴露给你看。我打一个比方/dev像是停车场入口的栏杆你只需要刷卡过去/sys却是整个停车场的监控中心哪个车位停着哪辆车、谁在管这个车位、车的充电状态怎么样全在这儿一览无余。对内核调试和驱动开发来说这个监控中心比栏杆重要得多。sysfs 的另一个特征是“活”的。你往/sys某个文件里写东西内核会立刻收到一个回调执行相应的函数你去读某个文件内核现场生成内容返回给你。它不是一个快照而是一面实时映射内核状态的镜子。因此它也非常适合做设备调试不需要写一堆 ioctl不需要重新编译用户态程序一根命令行就能触达内核里某个具体功能。1.2 它是如何长出来的kobject与设备模型想理解 sysfs绕不开 kobject。简单说kobject 是内核用来管理对象生命周期和对象间层级关系的一套基础设施。之前的内核2.4 及更早里设备信息靠 jeff laughs各写各的没有一个统一的方式让用户空间了解系统里究竟有多少设备、它们是什么类型、处于什么状态。sysfs 的出现其实是 Linux 设备模型重构的副产品。当时 Patrick Mochel 推动设备模型时把每个设备、驱动、总线都抽象成了 kobject而 kobject 天生需要一个地方“露面”。于是 sysfs 就自然生长出来了每个 kobject 在 sysfs 中对应一个目录每个属性对应一个文件对象之间的关联用符号链接表达。这里有一个关键点sysfs 并不是“文件系统设计会议”上讨论出来的产物而是设备模型这个上层建筑带来的必然结果。所以你研究 sysfs 时不要把它孤立地当成一种文件系统而是先认清它背后那棵“对象树”长什么样一切就豁然开朗了。设备模型里最重要的三个概念是总线bus、设备device、驱动driver。它们之间通过 kobject 的层次关系组织在一起sysfs 不过是将这棵对象树投影到了用户空间。所以你会看到/sys/bus、/sys/devices、/sys/class其实是在用不同视角观察同一棵对象树。2. 目录结构看一遍就记住了2.1 根目录下各子目录的用途我用随手ls /sys的输出做参考带你过一遍主目录。千万别背理解了“这棵树长什么样”之后你自然就记住了。/sys/devices这是整个设备树的根系统中所有真实存在的设备都会在这里挂一个目录路径一般按总线类型和地址层级排列。/sys/bus按总线类型组织里面每种总线platform、i2c、spi、pci、usb 等下面又有 devices 和 drivers 两个子目录分别列出挂在这条总线上的设备和驱动。/sys/class按设备功能归类比如net、leds、gpio、block、input。这是一种“按用途找设备”的视角。/sys/block块设备目录可以看到 sda、mmcblk0 之类属于历史遗留视角部分信息已被/sys/class/block覆盖。/sys/module已加载内核模块的目录每个模块一个目录里面包含参数、状态、引用计数等。/sys/dev字符设备和块设备按主次设备号做的符号链接映射。/sys/firmware、/sys/fs、/sys/kernel分别放固件相关信息、部分文件系统的特定状态如 cgroup、内核级的运行参数。很多人刚接触 sysfs 时最大的困惑是为什么同样一个设备我在/sys/bus/i2c/devices/1-0036能看到在/sys/class/hwmon/hwmon3也能看到在/sys/devices/platform/soc/xxxx.i2c/i2c-1/1-0036还能看到因为这三类路径是在用不同方式索引同一棵设备树前两个本质上是指向/sys/devices下真实目录的符号链接。这种“多视角”设计正好对应内核里kobject可以同时挂接在多个kset中的能力。对用户空间程序来说按class找设备最方便因为不需要关心设备是 i2c 还是 spi 接进来的按bus找则有利于排查驱动匹配问题。2.2 属性文件文件只是入口背后是一段C代码sysfs 里大部分常规文件叫“属性文件”attribute。内核中一个属性文件由struct attribute描述核心是name和mode分别决定文件名和读写权限。读操作最终会触发一个show()回调函数写操作触发store()回调函数。你可以这样理解/sys下你看到的“文件”本质上是一对函数指针的对外暴露。cat文件实际是调用内核里的show()函数把返回的字符串打印到终端echo xxx 文件实际是把字符串送进内核里的store()函数由它去解析并执行写入逻辑。属性文件有两种常见类型普通属性和二进制属性。普通属性以文本形式读写适合设备型号、状态、参数这类数据二进制属性则直接搬运原始数据块适合固件下载、寄存器转储等场景。你在驱动代码里能看到大量DEVICE_ATTR、DRIVER_ATTR、BUS_ATTR宏它们分别表示这个属性挂在 device、driver、bus 上最终会落到 sysfs 的不同层级中。理解“文件即回调”是十分重要的一环。很多人调试时发现写文件没反应第一反应是“文件是不是只读”但真正的问题往往是驱动同事只在show()里写了回显压根没实现store()。从用户角度看这个文件存在且能读但内核里没有对应的“接单员”来处理你的写入请求。后面我会专门聊这个问题。3. 实操从查信息到写驱动全流程体验sysfs3.1 先来读不写一行代码也能把硬件摸个底朝天我习惯把所有 sysfs 交互分为三种读状态、触发操作、配置参数。下面列几个我实测常用且极其稳定的查询命令你可以直接在自己的 Linux 机器上试。查 CPU 信息cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq直接读当前频率有些嵌入式平台没有 cpufreq 目录说明该 CPU 不支持调频。查 MAC 地址cat /sys/class/net/eth0/address比折腾 ethtool 快得多。查磁盘状态cat /sys/block/sda/stat或cat /sys/class/block/sda/stat能看到读写次数、合并次数、扇区数等内核统计实时更新。查设备挂载的驱动ls -l /sys/bus/platform/devices/.../driver符号链接直接指向驱动目录一眼看清绑定关系。查电源状态很多嵌入式板卡在/sys/class/power_supply/battery/下容量、电压、电流、状态都在这里比读/proc下的某些残留数据更权威。这些查询的价值在于当你的程序行为诡异时先用 sysfs 确认当前硬件状态。比如一个串口设备收不到数据先看/sys/class/tty/ttyS4/device/resources里的 IO 地址和中断号是否与设备树一致往往能立刻定位问题。再强调一个技巧/sys下很多文件是符号链接。你用ls -l能看到目标路径用readlink -f可以解析出真实路径。由于系统启动时设备注册顺序不一定一样符号链接指向的路径可能变化所以用户空间程序判断设备时优先用/sys/class这种稳定的视角而不是直接拼死记住某个深层设备路径。3.2 再试着写改一个“文件”就是控制一个设备读完之后我们来动手写。这里拿最常见的 GPIO LED 举例这种操作在嵌入式板卡上非常常用。许多板卡把 LED 导出到/sys/class/leds/下你只需要echo 1 /sys/class/leds/work-led/brightness echo 0 /sys/class/leds/work-led/brightnessbrightness文件的store()回调会解析用户传入的字符串转换成数值然后驱动底层去点亮或熄灭 LED。整个过程没有用户态程序参与也没有 ioctl内核里一个函数就搞定了。这就是 sysfs 的简洁之处它把驱动的控制逻辑和用户态交互之间的鸿沟压缩成了一个 C 函数。更常见的一个写入场景是 GPIO 的 direction。许多板卡的 GPIO 驱动支持echo out /sys/class/gpio/export echo 17 /sys/class/gpio/export echo out /sys/class/gpio/gpio17/direction echo 1 /sys/class/gpio/gpio17/value这里先export把某个 pin 从内核管辖下释放给用户空间再设置方向和电平。它背后的实现同样是调用驱动提供的回调函数。这种方式虽然不优雅且每次操作还有额外开销但配合 shell 脚本做硬件自检、产测工具时格外方便因为你不需要交叉编译任何程序。有一点必须提醒生产环境里不要依赖这种 shell 脚本去控制关键硬件效率低且容易出现竞态。sysfs 更适合调试阶段快速验证。正式功能请使用成熟的用户态库或按固定规则直接操作ioctl。3.3 从零导出一个自己的属性文件现在来到很多人真正关心的问题怎么在自己写的内核驱动里导出 sysfs 属性。我用最简单的一段代码说明。假设我有一个平台设备驱动想导出一个属性文件让用户空间能查看当前驱动内部的一个计数器并能通过写入来清零static int my_counter; static ssize_t counter_show(struct device *dev, struct device_attribute *attr, char *buf) { return sysfs_emit(buf, %d\n, my_counter); } static ssize_t counter_store(struct device *dev, struct device_attribute *attr, const char *buf, size_t count) { int val; if (kstrtoint(buf, 10, val) ! 0) return -EINVAL; if (val 0) my_counter 0; return count; } static DEVICE_ATTR_RO(counter); static DEVICE_ATTR_WO(counter_reset);创建属性后需要在驱动的 probe 函数里把它加到设备上static int my_probe(struct platform_device *pdev) { struct device *dev pdev-dev; int ret; ret device_create_file(dev, dev_attr_counter); if (ret) return ret; ret device_create_file(dev, dev_attr_counter_reset); if (ret) { device_remove_file(dev, dev_attr_counter); return ret; } return 0; }DEVICE_ATTR_RO和DEVICE_ATTR_WO是便捷宏前者自动生成show回调后者自动生成store回调并且分别把权限设为只读和只写。想同时支持读和写用DEVICE_ATTR_RW。这里的细节很关键sysfs_emit是内核提供的安全输出接口会自动处理页面溢出kstrtoint用于把用户传入的字符串转换成整数出错时返回-EINVAL用户空间会看到echo: write error: Invalid argument。接着用device_create_file逐一添加属性文件。更推荐的做法是定义struct attribute_group把多个属性打包后一次性注册static struct attribute *my_attrs[] { dev_attr_counter.attr, dev_attr_counter_reset.attr, NULL, }; ATTRIBUTE_GROUPS(my); static const struct platform_device_id my_ids[] { { .name my-demo, .driver_data 0 }, { } }; static struct platform_driver my_driver { .probe my_probe, .id_table my_ids, .driver { .name my-demo, .of_match_table my_of_match, .dev_groups my_groups, }, };把my_groups放在dev_groups字段后只要驱动与设备匹配成功内核会自动创建这一组属性文件不需要在 probe 里手动调用device_create_file也不用担心忘记清理。内核会自动管理生命周期驱动卸载时属性文件会一并消失。这看起来只是代码组织上的差异但在实际维护中差别很大。用attribute_group的方式更不容易泄漏资源也方便用sysfs自动生成设备节点。建议新驱动一律用attribute_group老驱动里看到的device_create_file单独调用尽量在重构时统一替换。当属性文件多起来时你还可以用bin_attribute处理二进制数据用is_visible回调控制属性在不同条件下显示与隐藏。比如某个传感器只有在芯片启动后才知道具体型号那么高级接口信息就可以放到is_visible里动态暴露。4. sysfs与身边的“兄弟”文件系统4.1 procfs、sysctl、devfs、sysfs 别搞混几乎每一个搞 Linux 的人都会在某个瞬间把“去 /proc 查一下”和“去 /sys 查一下”混着用然后被输出的内容搞晕。我平时被问到最多的问题之一就是这些东西到底有什么区别我把它们放一张表里慢慢讲。文件系统/路径挂载点主要作用典型内容维护建议procfs/proc进程与内核运行时信息进程列表、内存信息、CPU信息、中断信息不应把设备驱动属性往里塞sysctl/proc/sys内核运行时调参接口net.ipv4.ip_forward、vm.swappiness等用sysctl命令间接读写devfs/dev设备节点块设备、字符设备、tty、input 等现在由 devtmpfsudev 接管sysfs/sys设备模型与驱动状态设备树、总线、驱动绑定、属性配置驱动属性应导出到这里procfs 最初就是为了输出内核信息而被设计成文件系统后来逐渐变成了“什么都往里塞的大杂烩”。它和 sysfs 最本质的差异是procfs 偏重进程维度与系统全局统计sysfs 偏重设备/驱动/总线维度。比如查整机内存状态用/proc/meminfo合适查某块网卡的当前队列数去/sys/class/net/eth0/queues/更直观。sysctl 经常被误认为是一个独立文件系统实际上它就是 procfs 下的一个子集/proc/sys专门存放内核可调参数。它和 sysfs 属性文件虽然都是“读写一个文件来配置内核”但语义完全不同sysctl 面向内核全局调参比如 IP 转发开关、进程可打开文件数sysfs 面向具体设备实例比如某块网卡的 MAC 地址、某颗 LED 的亮度。devfs 的历史有点曲折。早期 Linux 在/dev下手动创建设备节点后来 2.4 时代有 devfs再后来被 udev 取代现在大多数发行版用 devtmpfs 配合 udev 在系统启动时自动生成设备节点。它和 sysfs 的协作关系是udev 接收内核通过 uevent 广播的“设备事件”再去/sys中查询设备的属性决定如何创建/dev下的节点名和权限。所以可以说没有 sysfs现代 udev 就失去了信息源。我在实际工作中常看到一种失误把设备参数丢到/sys/module/xxx/parameters/下试图通过它做运行时配置。模块参数确实可写但它的定位是加载时初始配置不是动态控制接口。动态控制设备请用 device attribute也就是我们前面写的DEVICE_ATTR_*。如果本来应该放在/sys/bus/xxx/devices/xxx/的属性被写到了/sys/module/xxx/别人维护时会非常困惑。4.2 一个事件的上天入地uevent 与 sysfssysfs 不只是静态信息展示它还承担了“将设备状态变化广播给用户空间”的渠道。这就是 uevent。每个 kobject 都可以发送环境属性当设备注册、注销、驱动绑定、驱动解绑时内核会生成一条 uevent 消息用户空间的 udev 收到消息后会去/sys里读取详细信息再创建或删除/dev节点。这解释了为什么/sys下有一些名为uevent的文件。你在 sysfs 中向该文件写入特定字符串就能手动触发一次消息发送。这在模拟热插拔、测试 udev 规则时非常有用。一般来说向/sys/class/mem/null/uevent写入change可以主动触发一次 change 事件向/sys/bus/platform/devices/xxx/driver/unbind写入设备目录名可以直接解绑驱动向/sys/bus/platform/drivers/xxx/bind写入设备名可以重新绑定。这种“手动驱动解绑-绑定”的调试验证手段在驱动开发早期简直救命。还有你需要留意 sysfs 的符号链接和硬链接问题。设备模型中的同一个设备可能被多个 kset 引用于是 sysfs 里会产生多个符号链接指向同一个真实路径。用户空间代码如果只缓存真实路径可能在设备重拔插后失效如果只用/sys/class视角则相对稳定。很多长期运行的服务程序莫名找不到设备排查到最后都是路径缓存问题。5. 常见问题与排查技巧实录5.1 高频问题速查表我整理了日常工作中经常遇到的 sysfs 相关问题标注了原因和排查方向。你可以把它当成一个速查手册遇到类似情况直接按表操作。现象可能原因排查/解决方案Permission denied无法读文件文件权限 mode 不对或 SELinux/AppArmor 拦截ls -l查看权限用setenforce 0测试调整驱动属性 mode写入返回Invalid argumentstore 回调解析失败格式不对确认写入字符串格式用hexdump查看实际内容看驱动解析逻辑写入返回No such device设备状态异常或属性不匹配当前设备dmesg查看内核日志检查设备是否 probe 成功读文件显示为空show 回调未返回内容或者文件为二进制属性用xxd以可观察的二进制方式访问检查驱动 show 实现符号链接指向的路径不存在设备已注册又注销或链接未更新重新触发 uevent检查驱动 remove 函数是否清理干净写文件无反应但也没报错store 回调返回了 count但没实际执行功能检查 store 中是return count还是返回了负数查看内核日志使用 udev 规则无效果事件时机与规则不匹配在/etc/udev/rules.d/中用udevadm monitor观察事件属性设备有多个属性目录路径不稳定不同视角的符号链接随注册顺序变化用/sys/class路径或使用稳定的by-path/by-id链接这张表背后其实都指向同一个方法论sysfs 文件只是个壳真正逻辑在内核的show/store回调里。只要思路切到“回调”模型很多诡异问题都能迎刃而解。5.2 几个我亲手踩过的坑第一个坑是权限模式与回调的错配。我记得有次调试一个传感器驱动导出的属性文件用DEVICE_ATTR_WO定义想让它只写。结果用户空间程序在读配置时直接Permission denied排查半天才发现程序里先open读文件检查版本但权限只有写于是 open 直接失败。这里正确的做法是用DEVICE_ATTR_RW同时在store()里校验版本号在show()里只输出版本号。这个“文件权限”和“业务是否需要读”的错配特别容易出现在赶工期的项目里。第二个坑是写入字符串解析容错不够。很多驱动的store()直接用sscanf(buf, %d, val)不做完整校验。用户echo100 时内核传过来的字符串其实带了一个换行符\nsscanf能正确处理但如果你echo 100 extra同样也能通过而且 extra 部分被忽略。这会导致不少“脏”输入被接受。后来我改用kstrtoint而不是sscanf它要求整个字符串都必须是合法整数否则返回错误。这算是一个代码编写习惯上的修正。第三个坑跟 sysfs 文件的生命周期有关。有一次我在驱动的 remove 函数里手动device_remove_file删除属性文件却忘了某个异步线程还持有该文件的引用导致内核直接报错。后来我改用attribute_group注册属性生命周期完全交给设备模型管理问题就消失了。所以写驱动的时候不要手动管理属性文件生命周期尽量把属性放在attribute_group里。第四个坑是写 sysfs 文件对 buffer 大小的敏感性。很多驱动show()里用sprintf(buf, ...)没有检查长度。旧内核 4K 页面下还行但新内核中sysfs_emit会对溢出做保护并主动截断。所以我建议你统一改用sysfs_emit不要在驱动里自己拼接字符串。它生成的输出末尾不带多余空格能确保每次读文件都是完整且稳定的一行。5.3 如何快速定位“我这个属性该放哪一层”经常有同学问想导出一个属性到底该挂在 device 上、driver 上、还是 bus 上我的判断标准很简单。属性描述设备特有的状态或能力比如传感器量程、固件版本放 device 层也就是/sys/bus/xxx/devices/xxx/。属性描述驱动全局行为比如驱动支持的调试开关、全局缓存开关放 driver 层也就是/sys/bus/xxx/drivers/xxx/。属性描述总线控制器自身的特性比如总线频率、仲裁策略放 bus 层。属性只是个调试辅助不想影响真实设备树可以放到模块参数里但要清楚它是模块级全局配置。按这个标准分类你在写驱动时基本不会纠结。如果业务上确实需要按设备实例来配置那就一定要放 device 层因为这样才能配合设备树实现每设备独立配置。6. 调试 sysfs 时我常用的三板斧6.1 用好 ls、cat、echo、dd 四个命令sysfs 调试的基础就是这四个命令但关键是你怎么组合它们。第一板斧是ls -l。不要只ls一定要-l看符号链接方向能够立刻看出目录之间的关联。比如/sys/class/gpio/gpiochip0到底指向哪个platform设备这时候ls -l就一目了然。第二板斧是cat。如果读文件返回内容和你预期不符用cat -A看看有没有隐藏字符有时可能是\n或空行输出导致解析失败。第三板斧是echo。写入前先想清楚这个文件是 RW 还是 WO否则会碰到权限问题。写入失败时立刻dmesg | tail看内核日志很多驱动会打印具体错误原因。第四板斧是dd。对于二进制属性用dd if/sys/class/xxx/data | xxd比cat可靠。cat会以文本方式读某些二进制文件中间遇到0x00就会出问题。6.2 配合 udevadm 监控设备事件当你不确定某个操作是否触发内核事件时用udevadm monitor来观察最直接。在一个终端里执行udevadm monitor --property在另一个终端执行设备插拔或驱动绑定操作。你会看到内核发出的 uevent 事件和属性键值对接着就能确定 udev 到底收到了哪些信息。这个工具在调试热插拔、设备节点权限问题时特别好用胜过反复猜测。6.3 用 inotify 监听 sysfs 变化严格来说sysfs 不是普通文件系统很多实现不支持 inotify。所以不要指望通过inotifywait监听/sys下的文件变化。如果你确实需要跟踪状态变化最佳做法是读文件前记录时间戳隔一段时间再读一次或者依赖内核主动发送的 uevent而不是依赖文件系统的通知机制。这一点很多人不清楚容易白费功夫。写在最后的体会最近我帮一个同事调一个 I2C 触摸屏驱动调试过程全靠cat /sys/bus/i2c/devices/1-0036/name确认设备有没有探测到再靠读取modalias确认驱动是否匹配。之前一直被各种 bug 折磨得焦头烂额换成按 sysfs 线索一步一步走半小时就把问题定位到了设备树中的中断号冲突。sysfs 看起来资源开销小、命令也简单但它真正的作用是帮你把内核里看不到的那棵设备模型树一点点“摸”出来。根据我个人的习惯写完驱动后一定会先手动把导出的属性文件逐个读一遍再尝试写入几个边界值确认异常输入会返回错误而不是稀里糊涂地忽略。然后写一个基于 sysfs 的冒烟测试脚本把关键属性全自动检查一遍确保改动不会破坏已有接口。这个方法成本极低但能挡掉很多回归问题。希望这篇文章能帮你在面对 sysfs 时少走点弯路用这套思路快速定位到“该看哪个文件、该写哪个文件、背后又是谁在相应”。