干内核开发这行早晚有一天会撞上设备模型这堵墙。我第一次调试一个I2C触摸屏驱动的时候明明驱动加载成功了设备却死活不出现在/dev目录下翻遍代码也不知道哪里出了问题。后来才想明白我把所有注意力都放在驱动的probe函数里却不知道在背后决定“驱动能不能被匹配、设备节点什么时候出现、用户态工具怎么跟内核协作”的正是《Linux设备模型》这套规则。不管你是做嵌入式开发、驱动移植还是系统裁剪的工程师搞懂Linux设备模型就等于拿到了内核世界里的一套交通规则。这篇文章不打算把代码逐行罗列一遍而是把设备模型从设计意图到实际调试按我自己的理解重新走一遍顺便把那些年踩过的坑一并交代清楚。1. 为什么要搞懂设备模型1.1 不是insmod完就完事了很多刚入行的人有个错觉驱动模块用insmod加载进内核设备就能用了。实际上insmod只是把一段二进制代码链接进内核并调用了模块的init函数。真正把设备和驱动绑到一块的行为发生在设备模型的匹配流程里。打个比方驱动就像一个认识“USB转串口芯片”的专家设备则是桌上那个USB转串口设备。专家再厉害如果没人把设备递到他面前他也没法工作。而设备模型里的“总线”就扮演了那个传话的人设备插上来的时候总线会通知所有注册过的驱动“这里有个新设备你们谁来认领”驱动如果能在自己的匹配表里找到对应的ID总线就负责安排双方见面也就是调用驱动的probe函数。所以如果你看到insmod成功、lsmod里也有模块但dmesg里没有probe信息不要急着怀疑硬件先检查设备模型里“设备”和“驱动”是否在同一个“总线”上匹配表有没有写对。设备模型不是某个深奥的内核模块而是整个Linux设备管理的地基。1.2 设备与驱动解耦让“设备”和“驱动”独立演进设备模型的核心设计目标是让设备、驱动、总线三者解耦。没有这套模型时内核版本不一样、板子硬件不一样驱动往往就要跟着改有了统一的抽象层同一份驱动代码可以在不同硬件平台之间复用。具体来说设备模型做了三件事设备只需要描述“我是什么、我在哪”比如我是I2C总线地址0x48上的温度传感器具体怎么做由驱动负责。驱动只需要声明“我能支持哪些设备”可以用ID表、设备树compatible、ACPI ID等方式描述。总线负责匹配和撮合它知道设备挂在哪条总线上也知道驱动的能力声明匹配成功就调用驱动的probe。这套设计带来的直接好处是一块开发板上更换主控芯片只要总线类型一致、设备树对应更新驱动基本不用动。而设备树的作用就是在“硬件描述”和“驱动代码”之间再隔一层让同一份内核镜像可以适应多种硬件。1.3 从板级硬编码到设备树硬件描述标准化以前写ARM平台的驱动要去arch/arm/mach-xxx下的board-xxx.c文件里注册平台设备和资源每换一块板子几乎就要改一次内核源码很不方便。后来社区把硬件描述抽到了设备树DTS文件里外设是不是存在、寄存器地址是多少、中断号是多少、用哪条总线和i2c地址全都在.dts文件里描述。设备树本身不参与匹配但设备模型会把它编译成的dtb转换成一组platform_device再走标准的总线匹配流程。今天在设备树里写一个节点内核启动时就能看到/sys/bus/platform/devices/下对应出现一个目录。这就是设备模型消费硬件描述信息的过程。从更宏观的角度看设备模型也是内核与用户态协作的桥梁。sysfs、uevent、devtmpfs这些机制都是基于设备模型的抽象层构建的这也是为什么“搞懂设备模型”这件事对做嵌入式、做服务器、做虚拟化的工程师都有意义。2. 设备模型的核心骨架kobject与sysfs2.1 kobject内核里的“基类”设备模型不是一个大一统的数据结构而是由很多小对象组合出来的。这些小对象共同的“基类”就是kobject。如果你熟悉面向对象编程可以理解为设备、驱动、总线这些核心对象都继承自kobject。kobject结构里包含了几个关键信息name对象的名字通常用在sysfs目录名里。refcount引用计数控制对象生命周期。parent父对象指针用来构建目录层级。ktype对象的类型决定了释放方式和属性操作回调。kset对象所属的集合用于把同类型的对象组织在一起。sd对应的sysfs目录项指向sysfs里的目录结构。实际使用中大部分驱动开发者不会直接操作kobject而是通过device、device_driver、bus_type这些更高层的封装间接使用它。但理解kobject的引用计数和release回调机制对排查内存问题非常关键。2.2 kset和ktype群体与行为的组织者kset是把同类型kobject组织起来的集合。比如/sys/bus/platform/devices下面的每个设备都是一个kobject它们共同归属于platform总线的devices_kset。kset的作用是把分散的对象挂到同一个父目录下并且让这个集合具有统一的“行为”。ktype负责定义一类对象的公共操作最典型的是三类回调release引用计数减到0时被调用负责释放对象内存这是必须实现的。sysfs_ops定义sysfs属性文件的读写操作也就是show和store。default_attrs定义默认属性列表旧版本内核里常用新内核逐步被attribute_group替代。只要理解了kobject里面嵌着kref引用计数归零时会回调ktype-release那么很多驱动模板里“‘xxx_release’函数不能为空”的要求就说得通了。这也是为什么你在阅读内核代码时几乎见不到一个完全没有release实现的设备对象。2.3 sysfs目录结构设备模型在用户态的样子sysfs是设备模型暴露给用户态的窗口挂载在/sys目录。你看到的/sys/bus、/sys/class、/sys/devices这些目录其实都是设备模型内部的层次结构。一次典型的设备注册会做这么几件事在/sys/devices/下创建该设备实际目录目录名由dev_set_name()决定。在对应总线的devices/子目录里创建一个符号链接指向真实目录。如果设备属于某个class还会在/sys/class/xxx/下创建另一个符号链接。设备的属性文件比如device name、uevent、modalias等会落实为目录下的普通文件。举一个实际例子你在/sys/bus/i2c/devices/下看到1-0048这样的名字说明这个设备挂在i2c总线1上地址是0x48。如果此时你想确认它对应的驱动可以看这个符号链接指向的真身再配合/sys/bus/i2c/drivers下的驱动目录确认匹配结果。ls -l /sys/bus/i2c/devices一看很多问题当场就能定位。2.4 生命周期管理release回调是最后的守望者设备模型里最容易出问题的地方是生命周期管理。设备对象可能同时被内核内部、sysfs、驱动模块等多方引用靠kref引用计数来保证“最后一个持有引用的人负责释放”。这里有个实际的经验如果你的驱动里实现了自己的device释放函数但忘记在device_register()失败路径上调用put_device()系统启动一段时间后可能会出现内存泄漏。更常见的是忘记给设备结构体提供release回调此时内核会打印类似“kobject: no release function for ...”。虽然系统不会立刻崩溃但这个对象的内存永远不会被释放反复加载卸载模块几次就能看到内存越用越少。所以在你自定义设备结构体时第一步不是急着注册而是把release回调写好。哪怕里面什么都不干只调kfree也得保证引用计数归零时有这个收尾函数兜底。3. 三大主角设备、驱动、总线怎么串起来3.1 bus_type、device、device_driver的数据结构要点设备模型中有三个核心角色总线、设备、驱动。用一个不严谨但好理解的比喻总线是红娘设备是新娘驱动是相亲对象。红娘手里有一本册子一边登记着设备一边登记着驱动两边都符合条件就能撮合到一起。在数据结构上bus_type不仅是一个标签它携带了一组操作回调match判断设备与驱动是否匹配这是核心。probe设备与驱动匹配成功后调用有些总线会在这一层做预处理。remove设备被移除或驱动卸载时调用。shutdown、suspend、resume电源管理生命周期钩子。device结构体描述一个具体的设备里面包含总线指针bus、父设备指针parent、设备名init_name、以及与总线相关的私有数据p。它并不直接保存所有硬件细节而是通过platform_data、resource、of_node等字段与具体的平台信息关联。device_driver结构体则描述一类驱动的能力。除了name和owner之外关键是三张表id_table传统ID匹配表常用于PCI、USB、I2C、SPI等总线。of_match_table设备树匹配表用于ARM等嵌入式平台。acpi_match_tableACPI匹配表用于x86或支持ACPI的ARM服务器。经常有人在一个驱动里同时提供id_table和of_match_table这在设备树环境下也能正常工作但要注意优先级关系下面详细展开。3.2 注册顺序与probe时机设备先还是驱动先设备模型有个特点设备注册和驱动注册谁先谁后最终都会尝试配对。这是因为总线在两边注册时都会执行一次“扫描现有对象”的动作。拿platform总线举例当驱动注册时总线会遍历已有的platform_device列表逐一调用match函数来寻找匹配的设备。当设备注册时总线也会遍历已有的驱动列表尝试反向匹配。所以不用担心顺序问题注册晚的一方会被“主动拉配”。实际的调用链大致是这样的driver_register() - bus_add_driver() - driver_attach() - bus_for_each_dev() - __driver_attach() - driver_match_device() - really_probe()在really_probe()里内核会先处理电源管理域和设备与驱动之间的关联再调用驱动里的probe函数。如果你在这条链路的任何一环断掉比如设备在dummy总线而驱动注册在platform总线那probe永远等不到。这个机制对调试的启发是如果发现驱动没有probe不要老盯着probe函数本身应该去看看总线上到底有没有对应的设备。用ls /sys/bus/platform/devices/和ls /sys/bus/platform/drivers/两边对照很多时候一眼就能发现问题。3.3 匹配机制详解ID表与设备树谁优先匹配机制是整个设备模型最容易被轻视、却又最影响实际效果的部分。以platform_bus为例它的匹配顺序通常是检查driver_override如果驱动主动指定了要绑定的设备名直接用它匹配。使用ACPI匹配表。使用设备树compatible匹配通过比对设备节点的compatible属性和驱动的of_match_table。使用id_table匹配比对platform_device的name字段。如果驱动的name和设备名一致也算匹配成功。很多嵌入式开发者在设备树里写了一个节点compatible字符串明明和驱动代码里相同却始终probe不了。大多数情况是没检查of_match_table的compatible字符串里是否带了厂商前缀比如vendor,device这种格式而在DTS里只写了device。这种字符差异光靠肉眼很难发现建议用cat /sys/devices/.../of_node/compatible去看设备树实际暴露给驱动的字符串再和驱动源码中的compatible对比。3.4 驱动模型的外延电源管理与热插拔设备模型的价值不只在匹配设备它还是Linux电源管理和热插拔系统的底座。常见的runtime PM框架会在设备模型注册时初始化dev_pm_domain和pm操作电源管理钩子与设备lifecycle是绑定的。一个典型的场景设备空闲时自动挂起需要使用前马上唤醒。这种动态电源管理就是通过设备模型里的pm回调实现的而不是每个驱动各写一套。bus_type里也有pm方法总线把设备的电源管理操作统一接好驱动只需要关注自己该做的部分。热插拔则是通过uevent机制实现的。设备插入时内核会生成一个add事件设备拔出时会生成一个remove事件。不管是USB、PCIe还是SD卡事件流程几乎一样设备模型负责产生事件用户态udev负责监听并处理。理解了这条链路调试热插拔时就不会没头绪。4. 从内核到用户态uevent与devtmpfs4.1 uevent的发送机制设备模型除了在内核态维护结构之外还要把“发生了什么”通知给用户态。这个通知就是uevent。kobject_uevent()是核心函数它会根据kobject所属的kset调用相应的uevent_ops填充事件环境变量再通过两种途径传给用户态传统方式调用/sbin/hotplug或/sbin/mdev之类的用户态helper。主流方式通过netlink socket组播发送udev监听的就是这个通道。一个典型的uevent会包含ACTIONadd、DEVPATH/devices/pci0000:00/...、SUBSYSTEMusb、MAJOR、MINOR等信息。用户态程序拿到这些信息后可以决定如何创建设备节点、设置权限、加载固件等。如果你不希望系统有额外的udev服务但又要自动创建设备节点devtmpfs就是另一个更直接的机制它由内核直接维护在设备注册时自动在/dev下创建节点。很多嵌入式系统里既用devtmpfs又用mdev就是希望既能快速拿到节点又能用脚本处理额外的权限和链接。4.2 udev与devtmpfs如何协作devtmpfs和udev不是竞争关系而是分工协作。devtmpfs负责快速创建设备节点udev负责“精细加工”设置属组、权限创建/dev/xxx的友好链接甚至触发加载固件程序。举个例子插入一个USB转串口芯片内核里的USB驱动识别到设备设备模型马上调用device_add()同时devtmpfs立刻在/dev下创建ttyUSB0紧接着uevent传给udev。udev会读取设备的子系统信息根据规则文件决定要不要改成别的名字、要不要改权限。这一套流程对用户来说就是“插上就好用”。在做嵌入式系统时经常看到有人争论要不要udev。如果设备固定、权限要求简单只用devtmpfs其实已经能工作。但如果要用到/dev/input下的固定命名、自动挂载U盘、规则匹配等功能就绕不开udev。4.3 sysfs属性读写与回调设计设备节点有了之后用户态想主动跟驱动交互常用的接口就是sysfs属性文件。在内核驱动里定义一个属性通常用DEVICE_ATTR或者DEVICE_ATTR_RO、DEVICE_ATTR_RW这类宏。下面是一个标准写法static ssize_t status_show(struct device *dev, struct device_attribute *attr, char *buf) { return sysfs_emit(buf, %d\n, current_status); } static ssize_t status_store(struct device *dev, struct device_attribute *attr, const char *buf, size_t count) { int ret kstrtoint(buf, 10, current_status); if (ret 0) return ret; return count; } static DEVICE_ATTR_RW(status);在probe里用device_create_file()注册或者在驱动的attribute_group里统一注册。注意在新版本内核中优先使用sysfs_emit()而不是sprintf()因为前者能正确处理sysfs缓冲区的大小和边界。这里有一个容易踩的坑属性文件的名字直接对应/sys目录下的文件名如果命名不符合规范、使用特殊字符会导致用户态无法访问。另一个常见错误是在store回调里返回错误计数却忘了返回受控的写入长度应用层看到返回值不符合预期时可能反复重试。4.4 调试手段清单自己干活时我习惯准备一组命令逐层检查。下面是几个最常用的场景命令/方法用途查看设备是否存在ls -l /sys/bus/xxx/devices/确认设备有没有被注册查看设备与驱动绑定关系ls -l /sys/bus/xxx/drivers/xxx/确认probe是否执行过查看设备树compatiblecat /sys/devices/.../of_node/compatible比对驱动匹配表查看内核日志dmesg | grep -i xxx|probe|uevent快速定位probe失败原因监听热插拔事件udevadm monitor实时观察uevent是否发送查看设备节点编号cat /proc/devices确认主次设备号分配用这些命令组合起来能帮你把问题从“设备注册”到“用户态事件处理”的整条链路理清楚。我见过不少同事花一下午调probe最后只是总线类型配错了也有的人苦于/dev节点不出现最后发现是udev规则写得太苛刻。5. 常见问题与排查技巧实录5.1 probe没有调用先查匹配表再看总线probe函数没有被调用是驱动开发里最高频的故障之一。排查顺序我基本固定先确认设备是否存在再确认驱动是否注册成功最后确认匹配表。第一步ls /sys/bus/platform/devices/。如果对应设备目录都不存在说明问题出在更早的设备注册或设备树阶段。这时候检查DTS节点是否被内核正确解析make dtbs生成的dtb有没有烧录到正确分区。第二步ls /sys/bus/platform/drivers/你的驱动名/。如果驱动目录都没出现检查模块是否真的加载成功、module_init是否正确执行。第三步如果两边都存在但probe没调用用dmesg | grep -i platform可能看到与大会地址相关的报错。实在不行在driver_match_device附近加打印或者用perf probe动态插桩在内核的really_probe函数上打点就能看出是哪一步提前返回了。5.2 设备注册失败名字冲突与“bad name”设备注册失败的另一大类原因是dev_set_name()分配的名字与已有设备重复。内核在device_add()时会对同名设备做检查如果重名会返回-EEXIST并打印device_register: bad name之类的日志。解决办法也很简单给设备名加上序号。比如注册多个相同传感器时可以用dev_set_name(dev, temp-%d, index)保证名字唯一。地址类设备常见的是“总线号-设备地址”或“控制器序号”组合可以规避绝大多数冲突。另外如果使用device_create_with_groups()或device_create()时指定错误的class或parent指针也容易出现注册失败。排查时可以检查父设备是否已经注销因为设备模型里的层级关系要求父设备不能先于子设备消亡。5.3 sysfs读写异常回调与锁的经典教训sysfs属性文件出现读写问题常见原因有两个。第一是属性回调函数中的缓冲区处理不严谨比如用scnprintf()返回值拼错了长度、没有在字符串末尾补上终止符第二是并发访问导致数据不一致show和store同时执行时没有保护共享变量。正确的做法是在属性回调里尽量只做原子操作用device_attribute封装时不要执行耗时的睡眠操作因为/sys属性可能在中断或原子上下文附近被访问。如果确实需要睡眠考虑改用sysfscompletion机制或者直接把状态缓存到内核变量user态通过poll等待。有个实操细节store回调里解析用户输入建议用kstrtoint()或kstrtou32()这类函数不要自己写字符串转数字因为你无法预期应用层会传什么格式进来。顺便说一句调试属性文件时可以用strace观察应用层打开文件时的错误码避免只见树木不见森林。5.4 uevent不触发检查掩码与helper路径uevent不触发时很多人第一反应是“驱动没发事件”其实多半是环境配置问题。检查列表确认内核配置里包含CONFIG_NET和CONFIG_UEVENT_HELPER_PATH如果要使用hotplug helper路径必须可访问。确认udev服务已经启动并且监听的netlink socket没有被防火墙规则过滤。cat /sys/kernel/uevent_seqnum然后触发一次热插拔再cat一次。如果序列号没变说明内核侧根本没发出消息。确认设备的uevent属性文件存在内容里ACTION等信息是否正常。另外某些总线的设备节点没有通过kobject_uevent()发送事件而是由子驱动直接调用dev_info()这种情况下用户态可能收到的事件内容不完整排查时不要过度依赖udevadm monitor的文本要结合-p选项看属性。5.5 热插拔后服务卡顿的处理在低端嵌入式设备上热插拔瞬间可能出现系统卡顿。原因通常是devtmpfs创建节点和udev加载固件同时进行再加上内核里其他子系统在同一时间扫描总线一瞬间抢占资源。我的处理经验有三条第一确认udev规则里不要写过于宽泛的匹配规则每条规则尽量精确到子系统或vid/pid减少无效执行第二给udevadm settle留出时间重要服务如果依赖设备节点启动顺序上做同步第三如果是固件加载导致卡顿考虑提升CONFIG_FW_LOADER_USER_HELPER相关路径的优先级或者把固件固化到内核里。设备模型本身并不复杂复杂的是它和驱动、总线、用户态之间的交互关系。我一直觉得如果能把一次热插拔背后的完整链路讲清楚设备模型就算是真正入门了。我自己的体会是遇到设备相关的问题不要急着在probe函数里加打印先沿着设备模型的思路分两层查第一层看设备有没有出现第二层看匹配有没有成功。绝大多数“莫名其妙”的问题最后都落在“设备不在该在的总线上”或者“compatible字符串少了一个厂商前缀”这种细节上。最后再分享一个小技巧把下面这行命令存成别名调驱动时能省不少力alias syslsfor d in /sys/bus/*/devices/*/; do echo $d - $(readlink -f $d 2/dev/null); done这条命令会把所有总线下的设备目录和它们实际指向的路径打出来设备没有注册、目录错乱、链接失效这些情况基本一眼就能暴露。