1. 为什么设备模型是Linux内核里最值得啃的一块硬骨头搞嵌入式或者做驱动开发的朋友迟早都会撞上/sys目录下那一堆软链接、属性和uevent文件。刚开始你可能只是照着教程敲echo命令点个灯或者用cat读个温度值但一旦要自己写一个字符设备驱动、注册一个平台设备或者排查“为什么我的设备节点没生成”这类问题就会发现绕不开一个东西——Linux设备模型。我最早接触这块是在做一块ARM开发板的电源管理驱动时。当时设备树里写好了节点驱动也probe成功了但/sys/devices下面死活找不到对应的层级关系/sys/bus/platform/devices里也没有我那个设备的名字。折腾了大半天才搞明白问题出在device_register和device_add的调用顺序上以及bus、driver、device三者之间的匹配逻辑没理清楚。那次之后我下定决心把设备模型从头到尾捋了一遍看完之后确实有一种“相见恨晚”的感觉——原来内核里那么多看似零散的机制背后都是同一套模型在支撑。这篇文章就是把我自己啃设备模型的过程、踩过的坑、以及实际调试中用到的排查手段整理出来。核心会围绕kobject、kset、ktype、sysfs、bus/driver/device、class这几大块展开每一块都会结合内核源码里的关键结构和实际/sys下的表现来讲。不管你是刚学驱动的新手还是已经写过几个模块但总觉得“知其然不知其所以然”的老手应该都能从中找到对自己有用的东西。文章里涉及的内核代码以Linux 5.x/6.x主线为参考不同版本细节可能有差异但核心思想是一致的。2. 设备模型到底解决了什么问题2.1 从“一堆散装驱动”到“统一视图”的演进早期的Linux内核2.4及以前里驱动就是一堆注册到全局数组里的函数指针设备信息靠register_chrdev这类接口硬编码。那时候你要知道系统里有哪些设备基本只能靠/proc下面零散的文件而且每个子系统各搞一套网卡有网卡的表示方法块设备有块设备的USB又有自己的。这种“散装”状态带来几个很现实的问题电源管理没法统一遍历所有设备做休眠唤醒热插拔事件没法用统一的方式通知用户空间驱动和设备的匹配逻辑每个总线都要自己写一遍。2.6内核引入设备模型本质上是要建立一个统一的设备拓扑。这个拓扑要能回答几个问题系统里有哪些设备它们挂在哪条总线上由哪个驱动管理它们之间的父子关系是什么设备当前是什么状态在线、休眠、移除回答完这些问题电源管理、热插拔、sysfs展示、驱动绑定就都有了统一的抓手。你可以把设备模型想象成公司的组织架构图。kobject是每个员工的基本档案kset是部门bus是业务线device是具体岗位driver是岗位的任职资格。有了这套架构HR内核才能高效地做人员调动设备热插拔、绩效考核电源管理和信息查询sysfs。2.2 四个核心需求驱动了整套设计设备模型的设计不是凭空拍脑袋它背后有四个非常明确的需求在驱动。第一是统一的引用计数和生命周期管理。内核里对象随时可能被创建和销毁如果每个子系统自己管理引用计数很容易出现释放后使用或者内存泄漏。kobject提供的kref机制让所有设备对象共用一套引用计数规则谁引用谁加一用完减一减到零自动释放。这是整个模型能稳定运行的地基。第二是层次化的sysfs表示。用户空间需要一个稳定的、有结构的接口来查看和操作设备。sysfs把内核对象以文件和目录的形式暴露出来每个kobject对应一个目录每个属性对应一个文件。这种“一个对象一个目录”的映射关系让用户空间可以用ls、cat、echo这些最朴素的工具完成设备查看和控制。第三是驱动与设备的自动匹配。一条总线上可能挂多个设备一个驱动可能支持多种设备。设备模型通过bus_type的match回调让总线自己决定哪个驱动对应哪个设备。匹配成功后调用驱动的probe失败则调用remove。这套机制把“谁管谁”的逻辑从驱动里抽出来放到了总线层驱动只需要声明自己支持什么就行。第四是热插拔事件的通知。设备插入或移除时用户空间需要知道发生了什么。kobject_uevent机制让内核能主动向用户空间发送事件udev或mdev收到后创建设备节点、加载固件、执行规则。没有这套机制每次插U盘都得手动mknod显然不现实。2.3 一张图看懂kobject、kset、ktype的关系很多人初学时分不清kobject、kset、ktype这三个东西。我用一个类比来说明kobject是一个“文件”kset是一个“文件夹”ktype是这个文件的“操作手册”。kobject是设备模型的最小单元它本身不包含任何业务信息只提供引用计数、父子关系、在sysfs中的位置、以及一个名字。它嵌入在更大的结构体里比如struct device里就有一个struct kobject kobj成员。这种“嵌入”而不是“指针指向”的设计很关键因为这样可以通过container_of从kobject反推出外层结构体实现类似继承的效果。kset是一组kobject的集合它自己也是一个kobject所以可以形成树状结构。kset的主要作用是把同类对象组织在一起比如/sys/devices下所有设备构成一个kset/sys/bus下所有总线构成一个kset。ktype定义了这类kobject的通用操作最重要的是release回调引用计数归零时怎么释放内存和sysfs_ops属性怎么读写。同一个ktype的kobject共享这些操作避免每个对象都重复定义。概念角色关键成员类比kobject最小对象单元name, kref, parent, kset文件kset对象集合list, kobj, uevent_ops文件夹ktype类型操作release, sysfs_ops操作手册kref引用计数refcount借阅登记理解了这三者的关系后面看device、driver、bus、class的代码就会顺畅很多因为它们本质上都是在这套基础设施上做业务封装。3. kobject与sysfs设备模型的基石3.1 kobject的初始化与引用计数实操写一个最简单的内核模块来观察kobject的行为是理解它的最好方式。下面这段代码创建了一个kobject把它加到sysfs里然后通过引用计数控制它的生命周期。#include linux/kobject.h #include linux/module.h #include linux/init.h static struct kobject *my_kobj; static void my_kobj_release(struct kobject *kobj) { pr_info(my_kobj released\n); kfree(kobj); } static struct kobj_type my_ktype { .release my_kobj_release, .sysfs_ops kobj_sysfs_ops, }; static int __init my_init(void) { int ret; my_kobj kzalloc(sizeof(*my_kobj), GFP_KERNEL); if (!my_kobj) return -ENOMEM; ret kobject_init_and_add(my_kobj, my_ktype, NULL, my_device); if (ret) { kfree(my_kobj); return ret; } pr_info(my_kobj created\n); return 0; } static void __exit my_exit(void) { kobject_put(my_kobj); pr_info(my_kobj put\n); } module_init(my_init); module_exit(my_exit); MODULE_LICENSE(GPL);加载这个模块后/sys/my_device目录就会出现。kobject_init_and_add做了三件事初始化引用计数为1设置ktype把kobject加到sysfs的指定父目录下。卸载时调用kobject_put把计数减到0触发release回调释放内存。这里有个很容易踩的坑kobject_init_and_add失败后不能直接kfree而应该调用kobject_put。因为kobject_init已经把引用计数设为1了直接kfree会导致引用计数状态不一致。虽然在这个简单例子里看不出问题但在复杂场景下会引发难以追踪的bug。正确的做法是失败时也走kobject_put让release回调统一处理释放。另一个坑是release回调必须存在且不能为空。如果ktype里没有release内核在引用计数归零时会打印警告并拒绝释放造成内存泄漏。这是内核强制要求的因为kobject的生命周期必须由release来终结不能靠外部随意释放。3.2 sysfs属性文件的读写机制kobject本身只是个目录真正让用户空间能读写的是属性attribute。属性分两种普通属性和二进制属性。普通属性用struct attribute和show/store回调适合文本交互二进制属性用struct bin_attribute适合传输大块数据或二进制数据。下面是一个带属性的完整例子展示如何通过sysfs读写一个内核变量。static int my_value; static struct kobject *my_kobj; static ssize_t value_show(struct kobject *kobj, struct kobj_attribute *attr, char *buf) { return sprintf(buf, %d\n, my_value); } static ssize_t value_store(struct kobject *kobj, struct kobj_attribute *attr, const char *buf, size_t count) { int ret kstrtoint(buf, 10, my_value); if (ret) return ret; return count; } static struct kobj_attribute value_attr __ATTR(value, 0644, value_show, value_store); static struct attribute *my_attrs[] { value_attr.attr, NULL, }; static struct attribute_group my_attr_group { .attrs my_attrs, }; static int __init my_init(void) { int ret; my_kobj kzalloc(sizeof(*my_kobj), GFP_KERNEL); if (!my_kobj) return -ENOMEM; ret kobject_init_and_add(my_kobj, my_ktype, NULL, my_device); if (ret) { kobject_put(my_kobj); return ret; } ret sysfs_create_group(my_kobj, my_attr_group); if (ret) { kobject_put(my_kobj); return ret; } return 0; }加载后/sys/my_device/value就可以读写了。echo 42 value再cat value就能看到42。这里的关键点是show回调返回的是写入buf的字节数store回调返回的是消费的输入字节数。如果store返回0用户空间的写操作会认为什么都没写进去可能反复重试。如果返回负数表示出错。__ATTR宏的第二个参数是权限位0644表示所有者可读写、其他人只读。这个权限会直接反映到sysfs文件上。需要注意的是sysfs属性的权限检查是在VFS层做的但内核内部调用show/store时不做权限检查。也就是说如果你在代码里直接调用sysfs_notify或者通过其他路径触发权限位不起作用。权限只对用户空间通过文件系统访问有效。3.3 uevent内核向用户空间喊话的通道kobject还有一个重要能力是发送uevent。当设备状态变化时内核通过kobject_uevent向用户空间广播事件udev或mdev收到后执行相应动作。kobject_uevent(my_kobj, KOBJ_ADD); kobject_uevent(my_kobj, KOBJ_REMOVE); kobject_uevent_env(my_kobj, KOBJ_CHANGE, envp);KOBJ_ADD、KOBJ_REMOVE、KOBJ_CHANGE是最常用的三种。kobject_uevent_env可以附加自定义环境变量这些变量会出现在uevent消息里udev规则可以用它们做条件判断。uevent消息的内容包括ACTION、DEVPATH、SUBSYSTEM、SEQNUM等固定字段以及kset的uevent_ops里添加的字段。比如device的uevent会带上MAJOR、MINOR、DEVNAME这样udev才能创建设备节点。实测中经常遇到的问题是uevent发了但udev没反应。排查思路是先用udevadm monitor看内核有没有发出事件如果有事件但udev没处理检查udev规则是否匹配如果连事件都没有检查kobject_uevent的调用时机是否在kobject_add之前在add之前发ueventDEVPATH还不完整udev会忽略。注意在kobject_add完成之前调用kobject_uevent内核会打印警告因为此时kobject还没有有效的sysfs路径。正确的顺序是先add再uevent。4. bus、driver、device驱动模型的铁三角4.1 总线如何成为设备与驱动的红娘bus_type是设备模型里最核心的抽象之一。它代表一条总线比如platform、i2c、spi、usb、pci。每条总线维护两个链表设备链表和驱动链表。当新设备或新驱动注册时总线负责把它们配对。struct bus_type { const char *name; int (*match)(struct device *dev, struct device_driver *drv); int (*probe)(struct device *dev); int (*remove)(struct device *dev); void (*shutdown)(struct device *dev); int (*uevent)(struct device *dev, struct kobj_uevent_env *env); struct subsys_private *p; ... };match回调是总线的灵魂。它决定了一个驱动能不能管一个设备。platform总线的match逻辑很简单比较device的名字和driver的id_table或name。i2c总线则要比较设备地址和驱动支持的地址列表。usb总线要比较vendor id和product id。匹配成功后总线调用驱动的probe。如果probe返回0绑定成功/sys/bus/xxx/drivers/yyy/目录下会出现指向设备的软链接。如果probe返回负数绑定失败驱动会继续尝试匹配其他设备。这里有个设计上的精妙之处match和probe是分开的。match只做快速筛选不涉及硬件操作probe才真正初始化硬件。这样总线上挂很多设备时匹配过程可以很快完成只有真正匹配上的才走耗时的probe流程。4.2 手写一个platform驱动看匹配全过程platform总线是嵌入式开发里最常用的虚拟总线设备树里的节点最终都会变成platform_device。下面是一个完整的platform驱动例子展示从注册到probe的全过程。#include linux/platform_device.h #include linux/module.h #include linux/of.h static int my_probe(struct platform_device *pdev) { struct resource *res; void __iomem *base; int irq; dev_info(pdev-dev, probe called\n); res platform_get_resource(pdev, IORESOURCE_MEM, 0); if (!res) { dev_err(pdev-dev, no memory resource\n); return -ENODEV; } base devm_ioremap_resource(pdev-dev, res); if (IS_ERR(base)) return PTR_ERR(base); irq platform_get_irq(pdev, 0); if (irq 0) return irq; dev_info(pdev-dev, mapped at %p, irq %d\n, base, irq); return 0; } static int my_remove(struct platform_device *pdev) { dev_info(pdev-dev, remove called\n); return 0; } static const struct of_device_id my_of_match[] { { .compatible myvendor,mydevice }, { } }; MODULE_DEVICE_TABLE(of, my_of_match); static struct platform_driver my_driver { .probe my_probe, .remove my_remove, .driver { .name my-platform-driver, .of_match_table my_of_match, }, }; module_platform_driver(my_driver); MODULE_LICENSE(GPL);设备树里对应的节点mydevice10000000 { compatible myvendor,mydevice; reg 0x10000000 0x1000; interrupts 0 42 4; };加载模块后内核会遍历设备树为每个节点创建platform_device然后platform总线的match回调比较compatible字符串匹配成功后调用my_probe。在/sys/bus/platform/drivers/my-platform-driver/下会出现一个指向设备的软链接名字类似10000000.mydevice。这里的关键经验是of_device_id的compatible必须和设备树里完全一致包括厂商前缀。我见过有人写mydevice而设备树里是myvendor,mydevice结果死活匹配不上。另外MODULE_DEVICE_TABLE不是必须的但加上之后模块可以自动加载通过depmod生成别名省去手动insmod的麻烦。4.3 device和driver的绑定与解绑绑定关系建立后用户空间可以通过sysfs手动解绑和重新绑定这在调试时非常有用。# 查看当前绑定 ls /sys/bus/platform/drivers/my-platform-driver/ # 解绑 echo 10000000.mydevice /sys/bus/platform/drivers/my-platform-driver/unbind # 重新绑定 echo 10000000.mydevice /sys/bus/platform/drivers/my-platform-driver/bind解绑会调用驱动的remove重新绑定会再次调用probe。这个机制在调试电源管理、热插拔、驱动兼容性时特别方便不用反复卸载加载模块。但要注意不是所有驱动都支持手动绑定。如果驱动没有实现remove或者设备正在被使用比如挂载了文件系统解绑会失败并返回错误。另外手动绑定不会重新读取设备树设备资源还是之前那份所以如果设备树改了得重启或者重新加载设备树overlay。操作命令效果查看绑定ls /sys/bus/xxx/drivers/yyy/看到设备软链接解绑echo dev .../unbind调用remove绑定echo dev .../bind调用probe查看驱动信息cat /sys/bus/xxx/drivers/yyy/uevent驱动支持的设备ID5. class与device_create让用户空间看到设备节点5.1 class的作用与创建流程class是设备模型里面向用户空间的抽象。它把功能相似的设备归为一类比如所有输入设备属于input类所有块设备属于block类所有网络设备属于net类。class的主要作用是让udev知道该创建什么样的设备节点以及节点应该放在/dev下的哪个子目录。static struct class *my_class; static int __init my_init(void) { my_class class_create(THIS_MODULE, myclass); if (IS_ERR(my_class)) return PTR_ERR(my_class); return 0; } static void __exit my_exit(void) { class_destroy(my_class); }创建class后/sys/class/myclass目录出现。但此时里面是空的因为还没有设备属于这个类。5.2 device_create如何自动生成/dev节点device_create是连接设备模型和用户空间的最后一环。它创建一个struct device把它加到指定的class下同时触发ueventudev收到后自动在/dev下创建设备节点。static dev_t my_devt; static struct class *my_class; static struct device *my_device; static int __init my_init(void) { int ret; ret alloc_chrdev_region(my_devt, 0, 1, mydev); if (ret) return ret; my_class class_create(THIS_MODULE, myclass); if (IS_ERR(my_class)) { unregister_chrdev_region(my_devt, 1); return PTR_ERR(my_class); } my_device device_create(my_class, NULL, my_devt, NULL, mydev%d, 0); if (IS_ERR(my_device)) { class_destroy(my_class); unregister_chrdev_region(my_devt, 1); return PTR_ERR(my_device); } pr_info(device created: major %d minor %d\n, MAJOR(my_devt), MINOR(my_devt)); return 0; } static void __exit my_exit(void) { device_destroy(my_class, my_devt); class_destroy(my_class); unregister_chrdev_region(my_devt, 1); }加载后/dev/mydev0自动出现主设备号是动态分配的。device_create的最后一个参数是设备名格式%d会被替换成传入的minor号。这个节点是udev根据uevent里的DEVNAME创建的如果系统里没有udev比如某些精简嵌入式环境节点不会自动出现需要手动mknod或者用mdev。这里有个常见误区device_create创建的节点权限默认是0600只有root能访问。如果普通用户需要访问要么在udev规则里改权限要么在代码里设置dev_set_uevent_suppress后手动mknod。我一般是在udev规则里加一行SUBSYSTEMmyclass, MODE0666这样最干净。5.3 sysfs下的class目录结构解析创建完class和device后/sys/class/myclass/mydev0会出现里面有一堆文件和软链接。这些文件不是随便放的每个都有明确含义。文件/目录含义来源dev设备号 major:minordevice_add自动创建subsystem指向所属class软链接uevent设备事件信息device_add自动创建power/电源管理相关device_pm_init创建driver指向绑定的驱动绑定后创建软链接dev文件的内容是主设备号:次设备号udev就是靠读这个文件知道该创建什么节点的。uevent文件里包含MAJOR、MINOR、DEVNAME、DEVTYPE等字段手动cat一下就能看到内核准备发给用户空间的完整信息。提示如果/dev下节点没出现先cat /sys/class/myclass/mydev0/uevent看DEVNAME是否正确再用udevadm monitor看事件有没有发出去。两步一查基本能定位问题。6. 设备模型调试实战与常见问题排查6.1 用sysfs和debugfs定位设备注册失败设备注册失败是驱动开发里最常见的问题。内核日志dmesg通常会给出线索但有时候信息不够具体。这时候sysfs和debugfs就是最好的帮手。先看/sys/bus/xxx/devices/下有没有设备目录。如果没有说明device_register没成功或者根本没调用。如果有目录但/sys/bus/xxx/drivers/yyy/下没有软链接说明match失败或者probe失败。如果软链接有但/dev下没节点说明class或uevent有问题。debugfs里的/sys/kernel/debug/devices_deferred会列出probe被延迟的设备/sys/kernel/debug/driver_override可以强制覆盖驱动匹配。这些在调试复杂依赖关系时特别有用。# 查看所有platform设备 ls /sys/bus/platform/devices/ # 查看某个设备的uevent cat /sys/bus/platform/devices/10000000.mydevice/uevent # 查看驱动匹配状态 ls -l /sys/bus/platform/drivers/my-platform-driver/ # 查看延迟probe的设备 cat /sys/kernel/debug/devices_deferred6.2 引用计数错误的典型表现与修复引用计数错误是设备模型里最难查的bug之一。典型表现是模块卸载后/sys下目录还在或者dmesg里出现kobject: ... is not a valid kobject、refcount_t: underflow之类的警告。我遇到过一次驱动里在probe成功后又调用了一次get_device但remove里只调用了一次put_device导致引用计数永远减不到零设备无法释放。修复方法是在probe的错误路径和remove路径里成对处理引用计数用devm_系列函数可以省掉很多手动管理。// 错误示范probe里get了但remove里没put static int my_probe(struct platform_device *pdev) { get_device(pdev-dev); ... return 0; } // 正确示范用devm自动管理 static int my_probe(struct platform_device *pdev) { // devm_get_device不存在但可以用devm_add_action注册清理回调 return 0; }更稳妥的做法是尽量使用devm_前缀的函数它们会在设备解绑时自动释放资源。如果必须手动管理一定要在probe的每一条错误路径上都做好清理并且和remove路径保持一致。6.3 常见问题速查表现象可能原因排查方法解决/dev下无节点uevent未发或udev未处理udevadm monitor检查device_create调用probe不执行match失败对比compatible/id_table修正设备树或驱动ID目录残留引用计数未归零dmesg看kobject警告检查get/put配对属性读写失败权限或回调问题cat属性文件看错误码检查show/store返回值设备重复注册未检查返回值dmesg看EEXIST注册前先判断是否已存在卸载模块崩溃release为空或重复释放dmesg看oops确保release存在且只释放一次这张表里的每一条我都在实际项目中遇到过。最坑的是“目录残留”因为系统看起来还能跑但每次加载卸载模块都会多一个目录时间长了/sys下全是垃圾最后内存耗尽。根源就是引用计数没管好release没被调用。6.4 几个只有踩过才知道的实操心得第一kobject_init_and_add失败后不要直接kfree。前面提过但值得再强调一次。kobject_init已经把引用计数设为1直接kfree会让内核的引用计数状态和实际内存状态不一致。正确做法是kobject_put让release统一释放。第二sysfs属性文件的store回调里不要做耗时操作。sysfs的写操作是在持有kernfs_mutex的情况下进行的如果store里做睡眠、等待、大量计算会阻塞其他sysfs操作严重时导致系统卡死。需要耗时处理的用工作队列或内核线程异步做。第三device_create的设备名不要包含/。设备名会直接变成/dev下的文件名包含/会导致udev创建失败。也不要用空格和特殊字符用字母数字和下划线最安全。第四调试时善用dev_dbg和动态调试。pr_info打印太多会刷屏dev_dbg默认不输出需要开CONFIG_DYNAMIC_DEBUG后用echo file mydriver.c p /sys/kernel/debug/dynamic_debug/control打开。这样调试信息可以精确控制不影响正常使用。第五设备树里的status属性很关键。如果设备树节点写了status disabled内核不会为它创建platform_device驱动自然probe不了。我见过有人调试半天最后发现是设备树里status没改。7. 从设备模型延伸出去的两个实用方向7.1 基于设备模型的电源管理设备模型的一个核心应用是电源管理。每个struct device里都有struct dev_pm_info记录了设备的电源状态、唤醒能力、时钟依赖等信息。系统休眠时内核按照设备树的层级从叶子到根依次调用-suspend唤醒时从根到叶子调用-resume。static const struct dev_pm_ops my_pm_ops { .suspend my_suspend, .resume my_resume, .runtime_suspend my_runtime_suspend, .runtime_resume my_runtime_resume, }; static struct platform_driver my_driver { .driver { .name my-driver, .pm my_pm_ops, }, };runtime_suspend和runtime_resume是运行时电源管理设备空闲时自动进入低功耗状态。这套机制依赖设备模型里的父子关系和引用计数父设备不能比子设备先休眠子设备活跃时父设备不能休眠。理解设备模型对写好电源管理驱动至关重要。7.2 设备模型与热插拔的配合热插拔的完整流程是硬件检测到设备插入总线驱动创建device并注册kobject_uevent发送KOBJ_ADDudev收到后加载驱动模块、创建设备节点、执行自定义规则。设备移除时反向操作。# 查看热插拔事件 udevadm monitor --kernel --property # 手动触发uevent echo add /sys/bus/platform/devices/10000000.mydevice/uevent手动触发uevent在调试时很有用可以模拟设备插入观察udev和驱动模块加载是否正常。但要注意手动触发的uevent不会重新执行probe只是通知用户空间。要重新probe得走bind接口。设备模型这块内容刚看的时候会觉得概念多、结构绕但一旦把kobject、kset、bus、device、driver、class这几者的关系理顺再回头看内核代码和sysfs目录就会发现一切都顺理成章。我自己的经验是不要死记结构体成员而是打开一个真实的/sys目录对照着代码看每个目录和文件是怎么来的这样理解得最快也最扎实。后续如果要做更深入的定制比如自定义总线、自定义class属性、或者写一个完整的子系统设备模型都是绕不开的基础。
