干了这么多年 Linux 底层开发我越来越觉得真正把内核“撑起来”的那根骨架不是进程调度也不是内存管理而是设备驱动模型。很多人花大把时间啃 task_struct、mm_struct一碰到 device、driver、bus、class 就昏头觉得无非是一堆结构体挂链表没什么好聊的。可直到我自己写驱动、调板子、看启动日志才意识到如果不懂设备驱动模型你看到的内核是平的所有子系统都是散点一旦把模型吃透内核在你眼里立刻就有了层级有了流动性。设备什么时候出现、驱动什么时候被调用、sysfs 里的目录是怎么长出来的、为什么probe函数会被执行这些问题的答案全藏在这套模型里。那这篇文章就从我实际调试的经验出发把 Linux 设备驱动模型的整体思路、核心机制、匹配流程、实战示例以及它和内核底层能力的联动一层层拆开讲清楚。想入内核门、做驱动开发、或者搞嵌入式 BSP 的朋友这篇文章应该能帮你少走不少弯路。1. 为什么说设备驱动模型是内核的“骨架”1.1 内核里那么多子系统凭什么它最底层我们平时聊内核聊得最多的往往是进程调度、内存管理、文件系统、网络协议栈这些子系统看起来各自为政但底层都需要跟真实硬件打交道。CPU 要访问串口、磁盘要读写块设备、网卡要收发数据包这些动作最终都会落到“设备”上。而设备驱动模型就是内核用来统一管理“谁在什么总线上、哪个驱动对应哪个设备、什么时候加载、怎么通知用户态”的一套基础设施。你可以把调度器和内存管理想成公司的行政部门和财务部设备驱动模型则是整个公司的组织架构图。没有组织架构行政部门不知道谁负责哪块业务财务部不知道该给谁批预算。设备驱动模型就是这样一个公共底座让每个子系统都能在此基础上寻找自己的设备、绑定自己的驱动、创建对应的接口。比如块设备层需要调用存储设备驱动的接口网络层需要调用网卡驱动的 ops它们都不直接跟设备硬件发生关系而是通过设备驱动模型注册出来的对象去工作。1.2 模型要解决的三个核心问题我调试过 PCIe 网卡、USB 转串口、I2C 触摸屏回头总结这套模型无非在解决三件事。第一件事是热插拔和动态管理。USB 设备插上、拔掉PCIe 设备可能出现也可能消失内核需要知道设备什么时候加入、什么时候离开然后在运行过程中动态创建和销毁对应的数据结构而不是像老式内核那样把设备写死在代码里。模型通过device_register和device_unregister把设备的生命周期管起来让热插拔变得自然。第二件事是驱动与设备的解耦。驱动不再直接“指定”某个硬件地址而是声明自己能处理什么类型的设备。设备则表达出“我是谁、我在哪条总线上”。两边各自注册到同一条总线上由总线来负责匹配。驱动模块可以独立编译、独立加载、独立卸载不用把整个内核重新编译一遍这就是我们常说的动态加载机制的基础。第三件事是面向用户态的可视化和事件通知。设备模型把每个设备、驱动、总线都挂到一个叫 kobject 的对象体系里再通过 sysfs 导出到/sys让用户态用ls、cat就能看到设备结构。同时当设备出现或消失时内核发送 uevent 事件udev 收到之后自动创建/dev下的节点。没有这套机制用户态根本无法知道硬件发生了什么变化。2. 设备驱动模型的核心组成与关键机制2.1 device、driver、bus、class 各自扮演什么角色设备驱动模型里最常听到的就是 device、driver、bus、class这四个概念必须彻底搞清楚。我的理解是总线是路设备是路边的房子驱动是熟悉这条路线的快递员class 则是快递站里的分拣标签。没有总线设备和驱动就是孤岛谁也找不到谁没有 class设备只是一堆文件名用户不好分类。struct device描述一个物理或虚拟设备。它记录了设备在总线上的名字、设备号、资源、电源状态等。每个设备在被注册时会生成一个 kobject并挂到 sysfs 的某个目录下。struct device_driver描述一段驱动代码。它包含驱动的名字、所属总线的类型、以及关键的probe和remove回调。驱动不是说“我要控制哪个设备”而是说“我能服务哪类设备”。struct bus_type描述一种总线的匹配规则。PCI、USB、platform 都是常见总线。每一个总线都会维护两条链表一条挂设备一条挂驱动。总线上的match函数负责判断设备和驱动是否匹配。struct class描述设备的分类。例如串口设备属于 tty 类块设备属于 block 类杂项设备属于 misc 类。class 主要用来在/sys/class下生成分类目录并配合 udev 在/dev下创建节点。光看结构体定义很容易觉得抽象我建议你打开终端执行ls /sys/bus、ls /sys/class、ls /sys/devices把目录结构挨个看一遍。你会发现/sys/devices下是真实存在的硬件拓扑/sys/bus下是总线对设备和驱动的逻辑分组/sys/class下则是从用户使用角度对设备的分类。三个目录是从不同维度看同一套模型。2.2 藏在背后的 kobject 与 kref一切对象化的基础设备模型能做到如此统一背后有一个看不见的功臣就是 kobject。kobject 是内核中的“对象基类”几乎所有设备模型相关的结构体比如struct device、struct device_driver、struct bus_type都把 kobject 内嵌在第一个字段位置。为什么这么做因为内核需要一套统一的机制来管理这些对象的引用计数、命名、层级关系和 sysfs 导出。kref 则是基于 kobject 的引用计数器。当一个内核对象被多个子系统持有时只要有人引用它就不能随便释放只有当计数归零时才会调用release回调释放内存。我最开始在写驱动的remove函数时忘记给 device 结构体实现release回调结果卸载模块时内核直接打出一串警告Device xxx does not have a release() function。这个警告不是随便说说的它说明 kobject 机制发现这个对象没有释放函数如果把对象销毁掉就会内存泄漏。搞清楚 kobject 和 kref你对“设备模型管理生命周期”这句话会有真正切身的体会。2.3 sysfs 与 uevent模型对外开放的两个窗口设备模型再漂亮如果用户态看不到价值就大打折扣。sysfs 就是设备模型暴露给用户态的一扇窗。它通常挂载在/sys目录结构就是 kobject 层级结构的镜像。设备驱动模型每注册一个设备就会在 sysfs 下创建对应的目录和属性文件你cat这些文件实际上就是在调用对应 kobject 的 show 回调。另一扇窗是 uevent。内核在设备注册、注销时会向用户态发送一条事件包含设备路径、设备类型、动作add/remove等关键信息。用户态的 udev 守护进程收到事件后根据规则动态加载驱动并创建/dev节点。所以整个流程是设备插入 - 总线枚举 - 生成 kobject - 弹出 uevent - udev 收到消息 - 创建设备节点 - 用户态打开设备节点。很多时候我们以为设备节点是系统装好就有的其实背后完全是这套模型在驱动。3. 驱动与设备怎么“牵手”match 的完整过程3.1 从注册到绑定内核做了什么驱动和设备是如何走到一起的我刚开始看这段代码时总以为有一个全局的大循环在到处找配对其实不是。内核的做法非常巧妙每注册一个设备就会让设备所在的总线对所有驱动做一次匹配每注册一个驱动又会让该驱动所在的总线对设备列表再做一次匹配。这样无论设备先来还是驱动先来都不影响最终匹配结果。具体流程可以拆成这么几步总线注册bus_register初始化总线的设备链表和驱动链表。设备注册device_register创建 kobject挂入总线的设备链表然后调用总线的match函数看看有没有驱动已经等着了。一旦匹配成功立刻调用驱动的probe。驱动注册driver_register类似创建 kobject挂入总线的驱动链表再遍历设备链表找到所有还没绑定驱动的设备。每匹配到一个就调用一次probe。绑定成功设备结构体的driver字段指向驱动驱动结构体的 klist_devices 中加入该设备随后设备会出现在/sys/bus/xxx/drivers/yyy/目录下。这里的关键是总线的match函数。PCI 总线的 match 会比较 vendor ID 和 device IDUSB 总线的 match 会比较 interface 描述符而 platform 总线的 match 则会先看设备树 compatible 字符串再看 driver 的 id_table最后退回到平台设备名字字符串。理解了match的调度逻辑很多“driver 写好了怎么就是不 probe”的问题就迎刃而解。3.2 platform bus 与 device tree嵌入式场景的主角日常 x86 环境下PCI、USB、ACPI 承担了大量设备枚举工作但在嵌入式 Linux 里最常见的是 platform bus。platform bus 是一条虚拟总线专门用来承载那些既不在 PCI 上、也不在 USB 上、没有标准枚举协议的设备比如片上外设、GPIO 控制器、I2C 适配器。以前嵌入式开发者会在 BSP 里注册一堆platform_device在代码里指定内存地址、中断号、名字然后写对应的platform_driver来匹配它们。现在越来越多的平台改用设备树Device TreeBoard 级信息从 C 代码里剥离到.dts文件里。设备树中每个带compatible属性的节点在启动阶段会被解析成platform_device然后自动走上我们前面说的总线匹配流程。我在 i.MX6ULL 平台上移植内核时就踩过设备树匹配的坑。当时驱动代码里明明写了of_match_table也加了MODULE_DEVICE_TABLE(of, ...)但就是 probe 不了。后来用dtc反编译设备树对比 compatible 字符串发现设备树那边少了个逗号导致字符串不一致。这类问题用grep查dmesg根本看不出来必须静下心把两边的字符串逐字对齐。所以做嵌入式开发的朋友一定要养成“先看 dts再查 match”的排查习惯。3.3 probe 函数里到底该写些什么设备与驱动匹配成功之后内核会调用驱动的probe函数。很多新手不清楚probe和module_init里究竟该干什么。我打个比方module_init只是“快递员接单”告诉平台“我这里有个人会送快递”probe才是“正式开工”拿到具体地址后开始处理业务。在probe函数里常规动作包括从平台资源里获取内存地址和中断号、用ioremap映射寄存器、申请 GPIO 或 DMA 通道、注册中断处理函数、初始化自旋锁或互斥锁、注册字符设备cdev_add或者杂项设备misc_register、调用device_create生成/dev节点。所有跟具体设备相关的初始化都应该放在probe里而不是放在module_init里。因为module_init执行时驱动还不知道自己会绑定哪个设备只有probe才意味着真正和一个设备成功配对。remove函数则做反向操作注销设备、释放中断、释放映射、回收内存。一个合格的驱动必须保证probe和remove成对出现能够反复加载卸载而不出问题。我见过很多驱动能加载但一卸载就 panic基本上都是remove路径上资源处理不干净。4. 实战手写一个最小驱动验证模型全流程4.1 环境准备与内核配置注意点理论讲再多不如动手跑一遍。这里我以一个虚拟的 platform 设备为例从零编写一个驱动通过设备树完成匹配并在/sys下观察整个模型的表现。建议环境用一台 Ubuntu 虚拟机或者物理机提前安装好内核编译工具链并准备好当前内核版本的源码或 headers。安装依赖可以执行sudo apt-get update sudo apt-get install build-essential libncurses-dev bc flex bison libssl-dev接下来确认内核构建目录存在通常是在/lib/modules/$(uname -r)/build。如果没有可以先安装linux-headers-$(uname -r)。不过我更推荐直接准备一份完整的内核源码因为设备模型相关的头文件比较多只有构建目录完整编译时才不会缺这少那。另外为了让设备节点能自动创建内核需要开启 devtmpfs 和 uevent 支持。一般发行版默认都开着但如果你是裁剪内核请留意CONFIG_DEVTMPFS和CONFIG_UEVENT_HELPER否则会出现“设备注册了但/dev下没节点”的诡异问题。4.2 驱动代码与 Makefile下面是一段非常精简的 platform 驱动代码我在虚拟机上实测过用来验证设备驱动的匹配与 probe 流程完全够用。#include linux/module.h #include linux/platform_device.h #include linux/io.h #include linux/of.h #include linux/miscdevice.h #define DRIVER_NAME demo static int demo_open(struct inode *inode, struct file *filp) { return 0; } static ssize_t demo_read(struct file *filp, char __user *buf, size_t size, loff_t *off) { return 0; } static const struct file_operations demo_fops { .owner THIS_MODULE, .open demo_open, .read demo_read, }; static struct miscdevice demo_misc { .minor MISC_DYNAMIC_MINOR, .name demo, .fops demo_fops, }; static int demo_probe(struct platform_device *pdev) { int ret; ret misc_register(demo_misc); if (ret) { dev_err(pdev-dev, register misc device failed\n); return ret; } dev_info(pdev-dev, demo probed\n); return 0; } static int demo_remove(struct platform_device *pdev) { misc_deregister(demo_misc); dev_info(pdev-dev, demo removed\n); return 0; } static const struct of_device_id demo_dt_ids[] { { .compatible demo,chardev }, { } }; MODULE_DEVICE_TABLE(of, demo_dt_ids); static struct platform_driver demo_driver { .probe demo_probe, .remove demo_remove, .driver { .name DRIVER_NAME, .of_match_table demo_dt_ids, }, }; module_platform_driver(demo_driver); MODULE_LICENSE(GPL); MODULE_AUTHOR(Your Name); MODULE_DESCRIPTION(A simple platform driver for demo);对应的 Makefile 长这样obj-m : demo.o KDIR : /lib/modules/$(shell uname -r)/build PWD : $(shell pwd) all: $(MAKE) -C $(KDIR) M$(PWD) modules clean: $(MAKE) -C $(KDIR) M$(PWD) clean因为设备驱动模型是围绕设备树匹配展开的所以还需要一个虚拟设备树节点。你可以把下面这段追加到设备树的某个根节点下也可以在 bootloader 的 overlay 里动态加载/dts-v1/; / { demo0 { compatible demo,chardev; status okay; }; };如果不想折腾设备树也可以在驱动初始化时手动注册一个platform_devicestatic struct platform_device *demo_pdev; static int __init demo_init(void) { demo_pdev platform_device_register_simple(DRIVER_NAME, PLATFORM_DEVID_NONE, NULL, 0); return PTR_ERR_OR_ZERO(demo_pdev); } static void __exit demo_exit(void) { platform_device_unregister(demo_pdev); }这两种方式都能让驱动和设备在 platform 总线上碰面。但设备树方式更贴近真实嵌入式开发也更能体现of_match_table的匹配逻辑所以我更推荐先用设备树方式跑一遍。4.3 编译、加载、观察 sysfs 与日志在设备树节点准备好之后执行编译make如果一切正常目录下会生成demo.ko。接着加载模块sudo insmod demo.ko马上查看内核日志dmesg | tail -20如果匹配成功你会看到类似这样的输出demo demo0: demo probed这一步说明 platform 总线已经把设备树里的demo0节点转换成了platform_device并且与demo_driver完成了匹配probe函数被调用了。接下来验证模型导出的 sysfs 目录ls /sys/bus/platform/devices/ ls /sys/bus/platform/drivers/demo/ ls /sys/devices/platform/demo0/ cat /sys/class/misc/demo/dev你会在多个视角下看到同一个对象总线设备列表里有它驱动绑定目录里有它设备树生成的物理设备目录里也有它。这就是设备驱动模型“统一对象、多维视角”的直观体现。卸载驱动时执行sudo rmmod demo dmesg | tail -5又会看到demo removed的日志。反复 insmod / rmmod你就能感受到设备模型对驱动生命周期管理的精细程度。4.4 常见报错与排查技巧实战最常见的问题我整理成一张速查表遇到可以直接对照。现象原因处理思路insmod报No such device设备树节点和驱动compatible不匹配对比设备树中的 compatible 和驱动中的of_device_id看字符串是否一字不差加载成功但probe没被调用module_platform_driver注册时机和平台设备解析时机错位确认平台设备已经被注册如果是设备树确认节点在平台总线上dmesg 报Device demo does not have a release() function设备对象只被创建没有被正确释放为platform_device提供 release 回调或让platform_device_register_simple走标准注销流程make时报找不到 build 目录内核头文件未安装或源码路径不对检查/lib/modules/$(uname -r)/build是否存在必要时安装linux-headers加载后模块版本格式不符模块编译所用内核源码版本与运行内核不一致用uname -r确认版本确保 KDIR 指向真正的当前内核构建目录/dev下没有demo节点devtmpfs 未开启或 udev 规则没生效确认CONFIG_DEVTMPFSy确认misc类注册成功也可手动mknod验证我特别想强调一点设备模型相关的坑大多是“对象生命周期”问题而不是“语法”问题。你在编译阶段可能一切顺利但运行时却问题百出。这时候不要急着改代码先去看看/sys下对象是否存在、引用计数是否异常再回头看驱动和设备的匹配路径效率会高得多。5. 设备驱动模型与内核底层能力的联动5.1 file_operations、动态加载与安全拦截很多人分不清设备驱动模型和file_operations之间是什么关系这里我展开讲一下。设备驱动模型负责“把设备对象管理起来并让用户态能看到它”而file_operations则负责“用户态打开设备节点之后具体怎么读写数据”。驱动在probe阶段注册字符设备或 misc 设备时会把一组fops挂在设备上用户态对/dev下的节点执行open、read、write最终都会走到这组 fops。那么热词里提到的“动态加载 file_operations 拦截 read write”是怎么回事从设备模型角度看驱动仍然是通过标准file_operations挂到 VFS 层的但如果要做透明加密或安全审计就需要在 VFS 到驱动之间再插入一层拦截逻辑比如使用 Linux Security Module 或者更底层的 hook 机制。这些机制本身并不影响设备模型的匹配流程但它们能对已经绑定的设备节点做访问控制。换句话说设备模型负责“接通”安全模块负责“检查”。我在做一个数据防泄漏项目时就写过类似的东西。当时需要拦截对指定磁盘设备的 read/write最开始直接替换驱动里的 fops后来发现这样做非常危险因为设备模型和 VFS 会把 fops 指针缓存到多处动态替换容易引发竞态。稳妥的做法是在 fops 之外挂一层自己的处理逻辑或者用 lsm hook 对设备的读写操作做过滤。这算一个提醒fops 是驱动和 VFS 之间的契约别轻易在运行时撕裂它。5.2 内核同步方法在驱动中的落地设备驱动只要是并发的就绕不开内核同步。热词里的“linux内核同步的方法”在驱动开发里体现得尤其明显。设备模型本身在注册、注销设备时也会有并发操作内核内部用 mutex 和引用计数保护对象。而驱动里的probe、read、write、中断处理函数之间则会访问共享资源必须自己考虑同步。通常的做法是如果共享数据可能在进程上下文被多个线程访问就用 mutex 保护如果会在中断上下文或 bottom half 中被访问就用 spinlock 或者原子操作如果驱动需要等待某个异步事件完成用 completion如果有生产者和消费者模型用 waitqueue。我在写设备节点驱动时最简单的同步方式就是给读写都加一把 mutex虽然损失一些并发性能但能显著降低复杂度和踩坑概率。为什么不能全都用 spinlock因为 spinlock 在持锁期间不能睡眠而很多驱动操作比如 copy_to_user、ioremap、等待硬件响应都可能引起睡眠。反过来mutex 不能用在中断上下文因为中断处理函数不允许阻塞。所以在驱动里设计同步方案先得想清楚每一段代码运行在什么上下文。设备模型很少给你“一刀切”的答案它只是规定好对象生命周期而同步策略完全看你对设备行为的理解。5.3 从模型视角看内核裁剪、实时补丁与虚拟化最后把视野拉高一点。设备驱动模型和内核裁剪、实时补丁、虚拟化这些底层工作也密切相关。做内核裁剪时大家关注的是体积和启动时间但裁掉一个驱动远不止是去掉一个.ko文件还要考虑它所依附的总线、class、以及依赖的内核配置项。例如你把CONFIG_INPUT去掉不仅鼠标键盘驱动没了整个输入子系统的设备节点和事件接口也会一并消失。设备模型像一张大网裁剪时很容易牵一发而动全身所以每次裁剪完我都习惯在/sys下逛一圈看看哪些设备还在、哪些驱动没匹配上。实时补丁方面比如很多人提到的 RT 内核它对驱动最大的要求就是“临界区要短、关中断时间要可控”。设备模型自身维护锁和链表时也会影响到实时性。如果你的驱动在probe里做了大量耗时操作或者read路径持锁太久即使在 RT 内核上跑实时性也会被打折扣。所以实时补丁的优化既在调度器也在每个驱动的实现细节里。虚拟化场景里设备模型同样扮演关键角色。虚拟机里的 virtio 设备本质上是虚拟总线上的设备通过匹配 virtio driver 来绑定依然走bus_type的match、probe流程。每次我调虚拟化环境下的 IO 性能问题都会先在/sys/bus/virtio/devices下确认设备驱动绑定情况再往下排查队列深度和中断路由。说到底这些五花八门的底层能力全都离不开设备驱动模型这个共同底座。我个人在实际调试中的体会是设备驱动模型不是一段可以“背下来”的代码而是一种“对象化”的思维方式。你在/sys下看到的每一个目录背后都是一个 kobject驱动和设备之间的每一次绑定背后都是一次总线的 match 回调。真正吃透这套模型之后再看内核启动日志、看设备树解析、看驱动 probe 失败你会有一种“一眼看穿底牌”的感觉。做嵌入式或者内核驱动开发不怕起步慢怕的是只背 API 不追机制。这套模型值得反复锤。
干了这么多年 Linux 底层开发我越来越觉得真正把内核“撑起来”的那根骨架不是进程调度也不是内存管理而是设备驱动模型。很多人花大把时间啃 task_struct、mm_struct一碰到 device、driver、bus、class 就昏头觉得无非是一堆结构体挂链表没什么好聊的。可直到我自己写驱动、调板子、看启动日志才意识到如果不懂设备驱动模型你看到的内核是平的所有子系统都是散点一旦把模型吃透内核在你眼里立刻就有了层级有了流动性。设备什么时候出现、驱动什么时候被调用、sysfs 里的目录是怎么长出来的、为什么probe函数会被执行这些问题的答案全藏在这套模型里。那这篇文章就从我实际调试的经验出发把 Linux 设备驱动模型的整体思路、核心机制、匹配流程、实战示例以及它和内核底层能力的联动一层层拆开讲清楚。想入内核门、做驱动开发、或者搞嵌入式 BSP 的朋友这篇文章应该能帮你少走不少弯路。1. 为什么说设备驱动模型是内核的“骨架”1.1 内核里那么多子系统凭什么它最底层我们平时聊内核聊得最多的往往是进程调度、内存管理、文件系统、网络协议栈这些子系统看起来各自为政但底层都需要跟真实硬件打交道。CPU 要访问串口、磁盘要读写块设备、网卡要收发数据包这些动作最终都会落到“设备”上。而设备驱动模型就是内核用来统一管理“谁在什么总线上、哪个驱动对应哪个设备、什么时候加载、怎么通知用户态”的一套基础设施。你可以把调度器和内存管理想成公司的行政部门和财务部设备驱动模型则是整个公司的组织架构图。没有组织架构行政部门不知道谁负责哪块业务财务部不知道该给谁批预算。设备驱动模型就是这样一个公共底座让每个子系统都能在此基础上寻找自己的设备、绑定自己的驱动、创建对应的接口。比如块设备层需要调用存储设备驱动的接口网络层需要调用网卡驱动的 ops它们都不直接跟设备硬件发生关系而是通过设备驱动模型注册出来的对象去工作。1.2 模型要解决的三个核心问题我调试过 PCIe 网卡、USB 转串口、I2C 触摸屏回头总结这套模型无非在解决三件事。第一件事是热插拔和动态管理。USB 设备插上、拔掉PCIe 设备可能出现也可能消失内核需要知道设备什么时候加入、什么时候离开然后在运行过程中动态创建和销毁对应的数据结构而不是像老式内核那样把设备写死在代码里。模型通过device_register和device_unregister把设备的生命周期管起来让热插拔变得自然。第二件事是驱动与设备的解耦。驱动不再直接“指定”某个硬件地址而是声明自己能处理什么类型的设备。设备则表达出“我是谁、我在哪条总线上”。两边各自注册到同一条总线上由总线来负责匹配。驱动模块可以独立编译、独立加载、独立卸载不用把整个内核重新编译一遍这就是我们常说的动态加载机制的基础。第三件事是面向用户态的可视化和事件通知。设备模型把每个设备、驱动、总线都挂到一个叫 kobject 的对象体系里再通过 sysfs 导出到/sys让用户态用ls、cat就能看到设备结构。同时当设备出现或消失时内核发送 uevent 事件udev 收到之后自动创建/dev下的节点。没有这套机制用户态根本无法知道硬件发生了什么变化。2. 设备驱动模型的核心组成与关键机制2.1 device、driver、bus、class 各自扮演什么角色设备驱动模型里最常听到的就是 device、driver、bus、class这四个概念必须彻底搞清楚。我的理解是总线是路设备是路边的房子驱动是熟悉这条路线的快递员class 则是快递站里的分拣标签。没有总线设备和驱动就是孤岛谁也找不到谁没有 class设备只是一堆文件名用户不好分类。struct device描述一个物理或虚拟设备。它记录了设备在总线上的名字、设备号、资源、电源状态等。每个设备在被注册时会生成一个 kobject并挂到 sysfs 的某个目录下。struct device_driver描述一段驱动代码。它包含驱动的名字、所属总线的类型、以及关键的probe和remove回调。驱动不是说“我要控制哪个设备”而是说“我能服务哪类设备”。struct bus_type描述一种总线的匹配规则。PCI、USB、platform 都是常见总线。每一个总线都会维护两条链表一条挂设备一条挂驱动。总线上的match函数负责判断设备和驱动是否匹配。struct class描述设备的分类。例如串口设备属于 tty 类块设备属于 block 类杂项设备属于 misc 类。class 主要用来在/sys/class下生成分类目录并配合 udev 在/dev下创建节点。光看结构体定义很容易觉得抽象我建议你打开终端执行ls /sys/bus、ls /sys/class、ls /sys/devices把目录结构挨个看一遍。你会发现/sys/devices下是真实存在的硬件拓扑/sys/bus下是总线对设备和驱动的逻辑分组/sys/class下则是从用户使用角度对设备的分类。三个目录是从不同维度看同一套模型。2.2 藏在背后的 kobject 与 kref一切对象化的基础设备模型能做到如此统一背后有一个看不见的功臣就是 kobject。kobject 是内核中的“对象基类”几乎所有设备模型相关的结构体比如struct device、struct device_driver、struct bus_type都把 kobject 内嵌在第一个字段位置。为什么这么做因为内核需要一套统一的机制来管理这些对象的引用计数、命名、层级关系和 sysfs 导出。kref 则是基于 kobject 的引用计数器。当一个内核对象被多个子系统持有时只要有人引用它就不能随便释放只有当计数归零时才会调用release回调释放内存。我最开始在写驱动的remove函数时忘记给 device 结构体实现release回调结果卸载模块时内核直接打出一串警告Device xxx does not have a release() function。这个警告不是随便说说的它说明 kobject 机制发现这个对象没有释放函数如果把对象销毁掉就会内存泄漏。搞清楚 kobject 和 kref你对“设备模型管理生命周期”这句话会有真正切身的体会。2.3 sysfs 与 uevent模型对外开放的两个窗口设备模型再漂亮如果用户态看不到价值就大打折扣。sysfs 就是设备模型暴露给用户态的一扇窗。它通常挂载在/sys目录结构就是 kobject 层级结构的镜像。设备驱动模型每注册一个设备就会在 sysfs 下创建对应的目录和属性文件你cat这些文件实际上就是在调用对应 kobject 的 show 回调。另一扇窗是 uevent。内核在设备注册、注销时会向用户态发送一条事件包含设备路径、设备类型、动作add/remove等关键信息。用户态的 udev 守护进程收到事件后根据规则动态加载驱动并创建/dev节点。所以整个流程是设备插入 - 总线枚举 - 生成 kobject - 弹出 uevent - udev 收到消息 - 创建设备节点 - 用户态打开设备节点。很多时候我们以为设备节点是系统装好就有的其实背后完全是这套模型在驱动。3. 驱动与设备怎么“牵手”match 的完整过程3.1 从注册到绑定内核做了什么驱动和设备是如何走到一起的我刚开始看这段代码时总以为有一个全局的大循环在到处找配对其实不是。内核的做法非常巧妙每注册一个设备就会让设备所在的总线对所有驱动做一次匹配每注册一个驱动又会让该驱动所在的总线对设备列表再做一次匹配。这样无论设备先来还是驱动先来都不影响最终匹配结果。具体流程可以拆成这么几步总线注册bus_register初始化总线的设备链表和驱动链表。设备注册device_register创建 kobject挂入总线的设备链表然后调用总线的match函数看看有没有驱动已经等着了。一旦匹配成功立刻调用驱动的probe。驱动注册driver_register类似创建 kobject挂入总线的驱动链表再遍历设备链表找到所有还没绑定驱动的设备。每匹配到一个就调用一次probe。绑定成功设备结构体的driver字段指向驱动驱动结构体的 klist_devices 中加入该设备随后设备会出现在/sys/bus/xxx/drivers/yyy/目录下。这里的关键是总线的match函数。PCI 总线的 match 会比较 vendor ID 和 device IDUSB 总线的 match 会比较 interface 描述符而 platform 总线的 match 则会先看设备树 compatible 字符串再看 driver 的 id_table最后退回到平台设备名字字符串。理解了match的调度逻辑很多“driver 写好了怎么就是不 probe”的问题就迎刃而解。3.2 platform bus 与 device tree嵌入式场景的主角日常 x86 环境下PCI、USB、ACPI 承担了大量设备枚举工作但在嵌入式 Linux 里最常见的是 platform bus。platform bus 是一条虚拟总线专门用来承载那些既不在 PCI 上、也不在 USB 上、没有标准枚举协议的设备比如片上外设、GPIO 控制器、I2C 适配器。以前嵌入式开发者会在 BSP 里注册一堆platform_device在代码里指定内存地址、中断号、名字然后写对应的platform_driver来匹配它们。现在越来越多的平台改用设备树Device TreeBoard 级信息从 C 代码里剥离到.dts文件里。设备树中每个带compatible属性的节点在启动阶段会被解析成platform_device然后自动走上我们前面说的总线匹配流程。我在 i.MX6ULL 平台上移植内核时就踩过设备树匹配的坑。当时驱动代码里明明写了of_match_table也加了MODULE_DEVICE_TABLE(of, ...)但就是 probe 不了。后来用dtc反编译设备树对比 compatible 字符串发现设备树那边少了个逗号导致字符串不一致。这类问题用grep查dmesg根本看不出来必须静下心把两边的字符串逐字对齐。所以做嵌入式开发的朋友一定要养成“先看 dts再查 match”的排查习惯。3.3 probe 函数里到底该写些什么设备与驱动匹配成功之后内核会调用驱动的probe函数。很多新手不清楚probe和module_init里究竟该干什么。我打个比方module_init只是“快递员接单”告诉平台“我这里有个人会送快递”probe才是“正式开工”拿到具体地址后开始处理业务。在probe函数里常规动作包括从平台资源里获取内存地址和中断号、用ioremap映射寄存器、申请 GPIO 或 DMA 通道、注册中断处理函数、初始化自旋锁或互斥锁、注册字符设备cdev_add或者杂项设备misc_register、调用device_create生成/dev节点。所有跟具体设备相关的初始化都应该放在probe里而不是放在module_init里。因为module_init执行时驱动还不知道自己会绑定哪个设备只有probe才意味着真正和一个设备成功配对。remove函数则做反向操作注销设备、释放中断、释放映射、回收内存。一个合格的驱动必须保证probe和remove成对出现能够反复加载卸载而不出问题。我见过很多驱动能加载但一卸载就 panic基本上都是remove路径上资源处理不干净。4. 实战手写一个最小驱动验证模型全流程4.1 环境准备与内核配置注意点理论讲再多不如动手跑一遍。这里我以一个虚拟的 platform 设备为例从零编写一个驱动通过设备树完成匹配并在/sys下观察整个模型的表现。建议环境用一台 Ubuntu 虚拟机或者物理机提前安装好内核编译工具链并准备好当前内核版本的源码或 headers。安装依赖可以执行sudo apt-get update sudo apt-get install build-essential libncurses-dev bc flex bison libssl-dev接下来确认内核构建目录存在通常是在/lib/modules/$(uname -r)/build。如果没有可以先安装linux-headers-$(uname -r)。不过我更推荐直接准备一份完整的内核源码因为设备模型相关的头文件比较多只有构建目录完整编译时才不会缺这少那。另外为了让设备节点能自动创建内核需要开启 devtmpfs 和 uevent 支持。一般发行版默认都开着但如果你是裁剪内核请留意CONFIG_DEVTMPFS和CONFIG_UEVENT_HELPER否则会出现“设备注册了但/dev下没节点”的诡异问题。4.2 驱动代码与 Makefile下面是一段非常精简的 platform 驱动代码我在虚拟机上实测过用来验证设备驱动的匹配与 probe 流程完全够用。#include linux/module.h #include linux/platform_device.h #include linux/io.h #include linux/of.h #include linux/miscdevice.h #define DRIVER_NAME demo static int demo_open(struct inode *inode, struct file *filp) { return 0; } static ssize_t demo_read(struct file *filp, char __user *buf, size_t size, loff_t *off) { return 0; } static const struct file_operations demo_fops { .owner THIS_MODULE, .open demo_open, .read demo_read, }; static struct miscdevice demo_misc { .minor MISC_DYNAMIC_MINOR, .name demo, .fops demo_fops, }; static int demo_probe(struct platform_device *pdev) { int ret; ret misc_register(demo_misc); if (ret) { dev_err(pdev-dev, register misc device failed\n); return ret; } dev_info(pdev-dev, demo probed\n); return 0; } static int demo_remove(struct platform_device *pdev) { misc_deregister(demo_misc); dev_info(pdev-dev, demo removed\n); return 0; } static const struct of_device_id demo_dt_ids[] { { .compatible demo,chardev }, { } }; MODULE_DEVICE_TABLE(of, demo_dt_ids); static struct platform_driver demo_driver { .probe demo_probe, .remove demo_remove, .driver { .name DRIVER_NAME, .of_match_table demo_dt_ids, }, }; module_platform_driver(demo_driver); MODULE_LICENSE(GPL); MODULE_AUTHOR(Your Name); MODULE_DESCRIPTION(A simple platform driver for demo);对应的 Makefile 长这样obj-m : demo.o KDIR : /lib/modules/$(shell uname -r)/build PWD : $(shell pwd) all: $(MAKE) -C $(KDIR) M$(PWD) modules clean: $(MAKE) -C $(KDIR) M$(PWD) clean因为设备驱动模型是围绕设备树匹配展开的所以还需要一个虚拟设备树节点。你可以把下面这段追加到设备树的某个根节点下也可以在 bootloader 的 overlay 里动态加载/dts-v1/; / { demo0 { compatible demo,chardev; status okay; }; };如果不想折腾设备树也可以在驱动初始化时手动注册一个platform_devicestatic struct platform_device *demo_pdev; static int __init demo_init(void) { demo_pdev platform_device_register_simple(DRIVER_NAME, PLATFORM_DEVID_NONE, NULL, 0); return PTR_ERR_OR_ZERO(demo_pdev); } static void __exit demo_exit(void) { platform_device_unregister(demo_pdev); }这两种方式都能让驱动和设备在 platform 总线上碰面。但设备树方式更贴近真实嵌入式开发也更能体现of_match_table的匹配逻辑所以我更推荐先用设备树方式跑一遍。4.3 编译、加载、观察 sysfs 与日志在设备树节点准备好之后执行编译make如果一切正常目录下会生成demo.ko。接着加载模块sudo insmod demo.ko马上查看内核日志dmesg | tail -20如果匹配成功你会看到类似这样的输出demo demo0: demo probed这一步说明 platform 总线已经把设备树里的demo0节点转换成了platform_device并且与demo_driver完成了匹配probe函数被调用了。接下来验证模型导出的 sysfs 目录ls /sys/bus/platform/devices/ ls /sys/bus/platform/drivers/demo/ ls /sys/devices/platform/demo0/ cat /sys/class/misc/demo/dev你会在多个视角下看到同一个对象总线设备列表里有它驱动绑定目录里有它设备树生成的物理设备目录里也有它。这就是设备驱动模型“统一对象、多维视角”的直观体现。卸载驱动时执行sudo rmmod demo dmesg | tail -5又会看到demo removed的日志。反复 insmod / rmmod你就能感受到设备模型对驱动生命周期管理的精细程度。4.4 常见报错与排查技巧实战最常见的问题我整理成一张速查表遇到可以直接对照。现象原因处理思路insmod报No such device设备树节点和驱动compatible不匹配对比设备树中的 compatible 和驱动中的of_device_id看字符串是否一字不差加载成功但probe没被调用module_platform_driver注册时机和平台设备解析时机错位确认平台设备已经被注册如果是设备树确认节点在平台总线上dmesg 报Device demo does not have a release() function设备对象只被创建没有被正确释放为platform_device提供 release 回调或让platform_device_register_simple走标准注销流程make时报找不到 build 目录内核头文件未安装或源码路径不对检查/lib/modules/$(uname -r)/build是否存在必要时安装linux-headers加载后模块版本格式不符模块编译所用内核源码版本与运行内核不一致用uname -r确认版本确保 KDIR 指向真正的当前内核构建目录/dev下没有demo节点devtmpfs 未开启或 udev 规则没生效确认CONFIG_DEVTMPFSy确认misc类注册成功也可手动mknod验证我特别想强调一点设备模型相关的坑大多是“对象生命周期”问题而不是“语法”问题。你在编译阶段可能一切顺利但运行时却问题百出。这时候不要急着改代码先去看看/sys下对象是否存在、引用计数是否异常再回头看驱动和设备的匹配路径效率会高得多。5. 设备驱动模型与内核底层能力的联动5.1 file_operations、动态加载与安全拦截很多人分不清设备驱动模型和file_operations之间是什么关系这里我展开讲一下。设备驱动模型负责“把设备对象管理起来并让用户态能看到它”而file_operations则负责“用户态打开设备节点之后具体怎么读写数据”。驱动在probe阶段注册字符设备或 misc 设备时会把一组fops挂在设备上用户态对/dev下的节点执行open、read、write最终都会走到这组 fops。那么热词里提到的“动态加载 file_operations 拦截 read write”是怎么回事从设备模型角度看驱动仍然是通过标准file_operations挂到 VFS 层的但如果要做透明加密或安全审计就需要在 VFS 到驱动之间再插入一层拦截逻辑比如使用 Linux Security Module 或者更底层的 hook 机制。这些机制本身并不影响设备模型的匹配流程但它们能对已经绑定的设备节点做访问控制。换句话说设备模型负责“接通”安全模块负责“检查”。我在做一个数据防泄漏项目时就写过类似的东西。当时需要拦截对指定磁盘设备的 read/write最开始直接替换驱动里的 fops后来发现这样做非常危险因为设备模型和 VFS 会把 fops 指针缓存到多处动态替换容易引发竞态。稳妥的做法是在 fops 之外挂一层自己的处理逻辑或者用 lsm hook 对设备的读写操作做过滤。这算一个提醒fops 是驱动和 VFS 之间的契约别轻易在运行时撕裂它。5.2 内核同步方法在驱动中的落地设备驱动只要是并发的就绕不开内核同步。热词里的“linux内核同步的方法”在驱动开发里体现得尤其明显。设备模型本身在注册、注销设备时也会有并发操作内核内部用 mutex 和引用计数保护对象。而驱动里的probe、read、write、中断处理函数之间则会访问共享资源必须自己考虑同步。通常的做法是如果共享数据可能在进程上下文被多个线程访问就用 mutex 保护如果会在中断上下文或 bottom half 中被访问就用 spinlock 或者原子操作如果驱动需要等待某个异步事件完成用 completion如果有生产者和消费者模型用 waitqueue。我在写设备节点驱动时最简单的同步方式就是给读写都加一把 mutex虽然损失一些并发性能但能显著降低复杂度和踩坑概率。为什么不能全都用 spinlock因为 spinlock 在持锁期间不能睡眠而很多驱动操作比如 copy_to_user、ioremap、等待硬件响应都可能引起睡眠。反过来mutex 不能用在中断上下文因为中断处理函数不允许阻塞。所以在驱动里设计同步方案先得想清楚每一段代码运行在什么上下文。设备模型很少给你“一刀切”的答案它只是规定好对象生命周期而同步策略完全看你对设备行为的理解。5.3 从模型视角看内核裁剪、实时补丁与虚拟化最后把视野拉高一点。设备驱动模型和内核裁剪、实时补丁、虚拟化这些底层工作也密切相关。做内核裁剪时大家关注的是体积和启动时间但裁掉一个驱动远不止是去掉一个.ko文件还要考虑它所依附的总线、class、以及依赖的内核配置项。例如你把CONFIG_INPUT去掉不仅鼠标键盘驱动没了整个输入子系统的设备节点和事件接口也会一并消失。设备模型像一张大网裁剪时很容易牵一发而动全身所以每次裁剪完我都习惯在/sys下逛一圈看看哪些设备还在、哪些驱动没匹配上。实时补丁方面比如很多人提到的 RT 内核它对驱动最大的要求就是“临界区要短、关中断时间要可控”。设备模型自身维护锁和链表时也会影响到实时性。如果你的驱动在probe里做了大量耗时操作或者read路径持锁太久即使在 RT 内核上跑实时性也会被打折扣。所以实时补丁的优化既在调度器也在每个驱动的实现细节里。虚拟化场景里设备模型同样扮演关键角色。虚拟机里的 virtio 设备本质上是虚拟总线上的设备通过匹配 virtio driver 来绑定依然走bus_type的match、probe流程。每次我调虚拟化环境下的 IO 性能问题都会先在/sys/bus/virtio/devices下确认设备驱动绑定情况再往下排查队列深度和中断路由。说到底这些五花八门的底层能力全都离不开设备驱动模型这个共同底座。我个人在实际调试中的体会是设备驱动模型不是一段可以“背下来”的代码而是一种“对象化”的思维方式。你在/sys下看到的每一个目录背后都是一个 kobject驱动和设备之间的每一次绑定背后都是一次总线的 match 回调。真正吃透这套模型之后再看内核启动日志、看设备树解析、看驱动 probe 失败你会有一种“一眼看穿底牌”的感觉。做嵌入式或者内核驱动开发不怕起步慢怕的是只背 API 不追机制。这套模型值得反复锤。
