Linux驱动自动加载：从设备模型到udev与modprobe的完整链路

如果你手里有一块 Linux 开发板或者正在折腾某个 USB 外设的驱动多半遇到过这种尴尬手动 insmod 一下驱动设备立刻能用可一重启一切回到解放前再换台设备系统甚至不知道该加载哪个驱动。这就是 Linux 驱动自动加载要解决的核心问题。作为《Linux 驱动基础》系列的第二篇我打算把“驱动自动加载”这条链路从头到尾拆开讲清楚内核怎么描述设备、用户态的 udev 和 modprobe 怎么协作、设备树 compatible 是怎么和驱动对上眼的、模块的 alias 又是从哪里冒出来的。看完这篇你不仅能彻底搞懂自动加载的底层原理还能自己动手实现一个支持设备树匹配、热插拔自动 probe 的驱动并且知道它哪天不生效时该从哪里开始排查。1. 先理清驱动自动加载的三种路径与设计取舍1.1 为什么自动加载不是“开机执行一条命令”那么简单很多初学者会把自动加载理解成在 rc.local 里加一行 insmod或者在启动脚本里写死模块名。这样确实能跑但只能算“开机后手动执行了一次加载命令”离真正的自动加载差得很远。至少有三个场景是这种写法解决不了的设备不是开机时就存在比如 USB 外设可能在系统运行五分钟后才插上去rc.local 只管一次根本覆盖不到这种“热插拔事件”驱动之间存在依赖关系驱动 A 依赖驱动 B加载顺序错了就直接失败还有一个更底层的问题系统需要知道“当前这个新出现的设备到底该匹配哪个模块”这需要一套从硬件身份到模块名的映射机制靠脚本是表达不出来的。所以 Linux 实际提供了三个层次的加载机制按时机划分编译期直接把驱动编进内核镜像也就是 CONFIG_XXXy启动早期通过 initramfs 加载模块这些模块用于挂载根文件系统之前系统正常运行后由 udev 收到硬件事件并调用 modprobe 完成加载。设计一个产品时你需要想清楚目标设备的角色和出现时机。比如根文件系统挂在 SATA 硬盘上那 SATA 控制器驱动就必须编进内核或者放进 initramfs否则内核根本读不到硬盘而一个调试用的串口转 USB 芯片用第三层运行时加载完全够用还方便升级。1.2 三种方案的特点对比与选型取舍我把三种方案放到一张表里方便对照选择。方案加载时机适用场景优点缺点编译进内核 (CONFIG_XXXy)内核启动阶段根文件系统所在设备、核心外设、早期初始化硬件不依赖根文件系统可用性最高改动配置要重编内核镜像体积变大initramfs 模块预加载内核启动早期、挂载根文件系统之前存放根文件系统的磁盘控制器、网络驱动既保持模块化又能覆盖启动早期需要维护 initramfs 镜像更新模块后要同步重建udev modprobe 运行时加载设备出现时或热插拔时绝大多数外设USB/PCI/platform 设备按需加载、灵活、支持热插拔依赖用户态 udev根文件系统没挂载前用不了这里要注意内核本身几乎不做模块加载这件事。内核只负责把硬件信息通过 sysfs 暴露出来并且向上层发送 uevent 消息。根文件系统挂载之前只有 initramfs 里的程序和脚本能帮忙加载挂载之后才是 udev 和 modprobe 的主场。如果你在做嵌入式 Linux用的又是 busybox 这种精简环境没有 udev 守护进程那就要换用 mdev或者干脆选择方案一把驱动编进内核省掉一大堆用户态配置。这个权衡没有绝对正确的答案完全取决于设备的不可替代性和出现时机。2. 自动加载的底层逻辑设备模型、modalias 与 udev 的协作2.1 设备、总线、驱动三方是怎么完成“配对”的要理解自动加载必须先理解 Linux 设备模型。驱动开发里反复听到的 bus_type 就是那个负责“相亲”的角色。设备挂在总线上驱动向总线注册总线在合适的时候调用 match 函数把二者撮合到一起。以 platform 总线为例platform_match 的匹配顺序大致是先比较驱动 id_table 里的名字和设备名称再用 of_match_table 里声明的 compatible 字符串与设备树节点的 compatible 属性做比较最后还会看 acpi_match_table。USB、PCI 这类枚举总线则走另一条路驱动用 usb_device_id、pci_device_id 这样的 ID 表声明自己支持哪些 VID、PID、class 等信息。这里有个特别容易混淆的点到底是驱动的加载触发设备匹配还是设备的插入触发驱动匹配实际上两种情况都存在取决于事件发生的先后顺序。系统启动过程中通常设备先被注册到总线上等驱动模块随后加载并注册到总线时总线会对所有未匹配设备重新发起匹配一旦命中就直接调用 probe。反过来系统运行期间你插入一个 U 盘总线会收到设备注册事件然后遍历当前总线上已经注册的驱动列表找到匹配项就调用 probe。所以驱动模块的加载只是“把驱动挂上总线”它自己并不直接去找设备真正的匹配和 probe 调用是由总线来驱动的。2.2 modalias设备身份与模块名之间的“翻译官”当设备出现在系统里内核会为它生成一个 modalias 字符串。这个字符串把设备的关键身份信息压缩成一个文本通过 uevent 发给用户态。一个 platform 设备配合设备树时modalias 大致长这样of:NledT(null)Cmydev,led其中 N 后面是节点名字C 后面是 compatible 属性。如果是一个 PCI 设备模态别名就会长得多包含 vendor、device、subvendor 等一系列 ID。现在问题来了用户态拿到的只是这么一串字符串它怎么知道该加载哪个 .ko 文件答案是一个映射文件——/lib/modules/$(uname -r)/modules.alias。这个文件由 depmod 在安装模块时扫描生成内容就是形如“alias of:NTCmydev,led mydev_led”的对应关系。模块里的 MODULE_DEVICE_TABLE 宏起的就是这个作用。很多人以为它只是给内核用的一行声明其实它最重要的输出发生在编译阶段编译器把 ID 表信息塞进模块文件的 modinfo 段depmod 读取这些信息后才能在 modules.alias 里写下对应的别名。所以如果你写的驱动没有声明 MODULE_DEVICE_TABLEdepmod 就不知道该为它生成什么 alias设备出现时系统自然也无法把 modalias 和模块对应起来。可以通过 modinfo mydev_led.ko 查看模块中已声明的 alias这是判断自动加载配置是否有效的最直观手段。2.3 从 uevent 到 modprobe用户态的最后一棒设备加入系统时内核通过 netlink 把 uevent 事件发给用户态监听进程最常见的实现就是 udevd。udev 收到事件后会读取 /sys 下新设备的属性然后按规则文件匹配并执行动作。默认规则里已经有一条替我们完成了“按 modalias 加载模块”这件事它位于 /lib/udev/rules.d/80-drivers.rulesACTIONadd, SUBSYSTEM*, ENV{MODALIAS}?*, RUN{builtin}kmod load这条规则说的是只要有一个 add 事件并且事件的 MODALIAS 非空就交给内置的 kmod 命令去加载。kmod 收到 modalias 后会查找 modules.alias找到对应的模块名再调用 modprobe 做真正的加载包括解析依赖、传递模块参数。所以整个链路是硬件触发事件内核生成 modalias 并发出 ueventudev 匹配规则kmod 查表modprobe 加载模块模块的 init 函数执行并注册驱动总线匹配设备后调用 probe。有一个点你需要特别注意在这个故事里probe 的调用时间一定是在 modprobe 返回之前。也就是说驱动对设备的所有初始化工作发生在用户态加载模块的这个进程上下文中。如果你的 probe 函数里还去依赖某些用户态服务比如等待某个网络服务启动那必然会出问题因为此时用户态环境并没有准备好。3. 手把手实现从驱动代码到设备树再到系统配置3.1 一个带设备树匹配的 platform 驱动示例理论和机制讲再多不如直接写一个能自动加载的驱动。下面是一个最简单的 platform 驱动功能是匹配设备树节点并请求一个 GPIO控制一个 LED#include linux/module.h #include linux/platform_device.h #include linux/of_device.h #include linux/gpio/consumer.h static int led_probe(struct platform_device *pdev) { struct device *dev pdev-dev; struct gpio_desc *gpio; gpio devm_gpiod_get(dev, led, GPIOD_OUT_LOW); if (IS_ERR(gpio)) return PTR_ERR(gpio); dev_info(dev, led driver probed, gpio ready\n); return 0; } static int led_remove(struct platform_device *pdev) { dev_info(pdev-dev, led driver removed\n); return 0; } static const struct of_device_id led_of_match[] { { .compatible mydev,led }, { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, led_of_match); static struct platform_driver led_driver { .probe led_probe, .remove led_remove, .driver { .name mydev-led, .of_match_table led_of_match, }, }; module_platform_driver(led_driver); MODULE_LICENSE(GPL); MODULE_DESCRIPTION(Auto load demo led driver);几个关键点说明一下。devm_gpiod_get 是设备资源管理版本的 GPIO 请求接口它会自动从设备树的 led-gpios 属性里解析出引脚号驱动不需要手动释放probe 失败或驱动卸载时内核会代为清理。of_match_table 声明的是 compatible 字符串内核在匹配设备树节点时用字符串比对。module_platform_driver 是一个组合宏展开后等价于 module_init(led_driver_init) 加 platform_driver_register它在模块装载时注册驱动模块卸载时注销驱动省去了手写 init/exit 的样板代码。module 的编译文件也要配套好。假设源文件叫 mydev_led.cMakefile 这样写obj-m : mydev_led.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编译时执行 make ARCHarm CROSS_COMPILE你工具链前缀 all就会在目录下得到 mydev_led.ko。这个 .ko 文件里已经带上了 alias 信息可以用 modinfo 验证。3.2 设备树节点、模块安装与 depmod 的完整配置光有驱动代码还不够设备树里必须声明一个 compatible 属性为“mydev,led”的节点否则匹配无从谈起。以 i.MX 平台为例设备树里添加一个 led 节点led { compatible mydev,led; pinctrl-names default; pinctrl-0 pinctrl_led; led-gpios gpio1 3 GPIO_ACTIVE_LOW; status okay; };这里的 compatible 必须和驱动里 of_match_table 写的一致多一个字符、少一个字符都匹配不上led-gpios 属性会被 devm_gpiod_get 里的“led”参数解析属性名固定为“前缀-gpios”的格式。设备树编译成 dtb 后烧录到板子里系统启动时内核会把这个硬件信息注册成 platform_device然后一切就等着匹配了。驱动编译好之后安装步骤是固定的三步。先执行 make modules_install把 .ko 拷贝到 /lib/modules/$(uname -r)/ 对应的目录下再执行 depmod -a更新依赖和别名数据库最后可以手动 modprobe mydev_led 做一次完整测试。这里的关键坑在于 depmod 的版本要和当前运行的内核一致。如果你用的是交叉编译环境SDK 里通常有配套的 depmod 工具不能拿宿主机上的 depmod 处理 ARM 内核模块目录否则生成的 modules.alias 路径和内核发行版对不上系统还是找不到模块。嵌入式环境里如果不希望运行时执行 depmod也可以在 SDK 构建阶段就把模块和 modules.* 文件打包进 rootfs。如果你希望开机就加载模块而不管有没有设备还可以在 /etc/modules-load.d/ 下新建一个文件比如 mydev-led.conf内容就是一行模块名 mydev_led。systemd 会在启动时读取这些文件统一执行加载。这和 udev 自动加载是两个维度的东西一个是“不管设备在不在都加载”一个是“设备出现才加载”。做产品时根据需求组合使用。3.3 用 udev 规则做更精细的自动加载控制默认的 80-drivers.rules 已经覆盖了大部分“设备出现就加载驱动”的需求但实际产品里经常需要额外自定义 udev 规则。常见的需求有创建设备节点并设置权限根据设备的序列号给不同设备分配不同名称设备拔出时执行清理脚本。举一个实际例子假设驱动框架创建了名为 /dev/mydev_led 的节点想让普通用户可用# /etc/udev/rules.d/99-mydev-led.rules ACTIONadd, KERNELmydev_led, SUBSYSTEMmydev, MODE0664, GROUPdialout ACTIONremove, KERNELmydev_led, SUBSYSTEMmydev, RUN/usr/local/bin/led_cleanup.sh写完规则后执行 udevadm control --reload-rules 让新规则生效再触发一次事件 udevadm trigger 就能验证。需要提醒的是自定义规则里不要重复做“load module”这件事80-drivers.rules 已经做过了再写很容易出现重复加载或者加载时序问题。还有一个更隐蔽的细节默认的内核 uevent 在 sysfs 里把设备表示为一个 kobject驱动名对应的就是 device/driver 符号链接。如果 udev 规则里要匹配 kobject 名直接用 KERNEL 匹配即可要匹配设备树 compatible则用 ENV{MODALIAS} 里的字符串。实际调试里推荐先跑 udevadm monitor --kernel --property --udev观察事件携带的所有属性再决定规则写什么而不是凭记忆瞎猜。热插拔场景下这个命令能看到完整的 MODALIAS 和驱动加载动作是排查 udev 规则不生效的好帮手。4. 验证与排障自动加载不生效的定位思路4.1 从 modinfo、lsmod、dmesg 三条线索查起自动加载不生效时先别急着改驱动按顺序做三件事确认状态。第一确认模块本身带 alias 信息在模块目录下执行 modinfo mydev_led输出里必须有 alias 一行比如$ modinfo mydev_led filename: /lib/modules/6.1.0/extra/mydev_led.ko alias: of:N*T*Cmydev,led license: GPL description: Auto load demo led driver如果没有 alias 行回头检查 MODULE_DEVICE_TABLE 是否声明depmod 是否重新跑过。第二手动模拟加载执行 modprobe mydev_led观察返回值和 dmesg 输出。如果手动加载成功且 probe 被调用说明驱动本身没问题问题出在事件到 modprobe 的链路。第三检查设备树节点在运行时是否还存在在板子上执行 ls /sys/firmware/devicetree/base/led能看到节点说明设备树已经解析成功再执行 ls -l /sys/bus/platform/devices/led/driver看 driver 是否指向我们的驱动如果没有指向就是匹配失败。我通常还会看一眼 /sys/bus/platform/drivers/mydev-led/ 目录如果下面已经出现 led 这个符号链接证明驱动和设备已经绑定成功。到这里还没问题的话再回到 udev 那一步用 udevadm monitor 观察事件确认内核是否发出了带 MODALIAS 的 uevent。这套排查顺序基本能把问题定位到模块、设备树、匹配过程、udev 规则这四个环节之一。4.2 常见问题速查自动加载失败的典型场景我整理了平时遇到最多的几类问题做成速查表方便对照。现象可能原因排查方法modprobe 提示找不到模块modules.dep 未更新或模块路径不对检查 /lib/modules/$(uname -r)/ 下是否有对应 .ko重新 depmod -a设备在系统里但 probe 没被调用compatible 不匹配或设备树节点缺失对比 dts 与 of_match_table检查 /sys/firmware/devicetree/base/insmod 成功但 modprobe 失败模块依赖未安装modprobe --show-depends 查看依赖关系插上设备后没有自动加载动作udev 规则未匹配或 kmod 不可用udevadm monitor 观察 MODALIAS 是否上报手动 insmod 能工作重启后失效模块未加入 modules-load.d 或 initramfs 未更新更新 initramfs或添加 /etc/modules-load.d/ 配置modinfo 能看到 alias 但系统轮不到加载内核版本和模块版本不一致uname -r 确认内核版本重新编译模块4.3 一次设备树 compatible 改动引发的“玄学”故障最后分享一个我实际踩过的坑很有代表性。有一次板子上换了新版内核设备树里 led 节点的 compatible 从“mydev,led-v1”改成了“mydev,led-v2”但驱动里的 of_match_table 还停留在 v1。当时的现象特别诡异modprobe 加载模块后没有报错dmesg 里也没有 probe 输出设备树节点 ls 也存在驱动注册也成功可就是没绑定。折腾了半天最后我用 ls -l /sys/bus/platform/devices/led/driver 一看driver 是个空链接才意识到是 compatible 对不上。这类问题的麻烦之处在于它不会给你一个清晰的错误日志一切看起来都很正常只是没配对。现在我的习惯是在驱动里用 dev_dbg 或 dev_info 在 probe 入口打一条日志同时在 module_init 里注册驱动后主动调用 bus_for_each_dev 扫描一下当前总线设备把每次匹配状态清楚地打印出来。从那次之后只要发现驱动加载了但设备没有 response第一件事就是检查两边 compatible 字符串是否完全一致包括大小写和下划线。另外一个相关的经验是设备树节点里如果有 status disabled内核同样不会注册这个 platform_device匹配也就无从谈起排障时也要留意。如果你在调试的是 USB 设备排障思路略有不同。USB 设备出现时内核会把 VID、PID 组合起来上报 MODALIAS你只需要用 lsusb 查看设备 ID再和 usb_device_id 表对照即可。但 platform 设备没有这么直观的 ID只能通过设备树路径去溯源这就是为什么设备树匹配的错误大多出在字符串细节上。热插拔总线和静态设备树两种场景的排障思维要分开不能混在一起。写在最后自动加载是驱动设计的一部分而不是事后的配置项我个人写了几年驱动后的最大体会是自动加载这件事不该等到驱动写完了才想起来要配。正确的做法是在设计驱动结构时就先想清楚设备走的是哪条总线、用什么方式被枚举、内核靠什么标识认出它。声明好 MODULE_DEVICE_TABLE确定好 compatible 字符串把驱动初始化放到 module_platform_driver 这类组合宏里后面你甚至不需要写一行用户态配置系统就能自动完成加载。真正的产品环境里能少一个手动步骤就少一个隐患这比任何技巧都实在。下一篇我会继续讲字符设备节点怎么在 probe 里自动创建顺便把 class_create、device_create 这几个常用 API 的坑也填一填。