第91期 | 驱动先认亲，再谈干活

操作系统 · 2026-10-28 · 九羲科技

第十章前两期，一期数了驱动有多大，一期讲了接口为什么不稳。这一期收束第十章，问最底层的一步：驱动动手之前，怎么知道眼前这块硬件是谁。认错了人，后面翻得再准也是白翻。

一、没有总线认领，驱动无从下手

2.5 开发周期的目标之一，就是给内核造一个统一的设备模型。Patrick Mochel 的设备模型文档起草于 2002 年 8 月 26 日、2006 年 1 月 31 日更新，里面把旧局面说得很直：以前每种总线各有一套自己的设备清单，没有统一的结构¹。2.6 的模型把这件事收成三方：总线负责发现设备，驱动负责认领，匹配上了才调 probe¹。认领在先，干活在后，这个顺序就是驱动模型的全部尊严。

PCI 那边的硬件会自己报到：插上卡，总线枚举就能读到厂商号与设备号，内核按号找驱动。麻烦的是另一大类硬件：片上系统里直接挂在 CPU 地址线上的外设，串口、I2C 控制器、GPIO、时钟、电源，它们自己不会报到，内核也不知道它们在哪个地址、走哪根中断线。早期的办法是板级文件：每块板子在内核里写一份 C 代码，把地址、中断、时钟硬编码进去。板子一多，板级文件就跟着多，同一个串口驱动要在几十份板文件里重复出现，改一处地址，要翻一堆文件。

设备树就是把这份“户口本”从 C 代码里抽出来的办法：用文本描述一台机器上有哪些硬件、各自在什么地址、用什么中断，编译成二进制 blob，由引导程序交给内核²。格式源自 OpenFirmware，早就存在，Linux 只是把它接了过来。2011 年前后，在 ARM 上用设备树还有争议；据 LWN 回顾，争议过后板级文件基本退场，内核树里的设备树文件约有 2400 个³，重点不在 2400 这个数，而在方向：描述归描述，驱动归驱动，两边不再绞在一起。

认亲的动作本身很具体。设备树节点里有一串 compatible 字符串，比如 smsc,lan91c111；驱动带一张匹配表，字符串对上了，probe 才会被调⁴。probe 里再从节点取 reg 里的地址与大小、interrupts 里的中断号，而不是在驱动里把地址写死⁴。compatible 还可以列多个，从最具体的型号一路 fallback 到通用的家族名，认不准全名时，至少能按家族先把活干起来。

还有顺序这一关。probe 的时候，依赖的时钟、电源、GPIO 可能还没准备好，内核文档给出的办法不是硬上，也不是永久失败：返回 -EPROBE_DEFER，核心把设备放进延迟探测列表，等别的驱动成功之后再重试⁵。认亲不是一次性的点名，是一张带重试的等齐清单。孙过庭《书谱》里那句“初学分布，但求平正；既知平正，务追险绝；既能险绝，复归平正”⁶，放在这里正合适：先把位置摆平正，也就是先把描述摆清楚，再谈驱动里的险绝招数，终究要复归到统一的模型里。

设备树节点、总线、驱动三方认亲：字符串对上才调 probe，依赖没齐就先等。程序绘制概念示意图。

二、AI 时代的认亲，改成认能力

2026 年 10 月 21 日，Collabora 讲 Tyr 驱动上游进展的文章，正好是这张认亲表的新注脚⁷。Tyr 是把 Arm Mali-G610 已有的 C 语言 Panthor 驱动原样移植成 Rust，目标是对用户态完全透明。2025 年 11 月随 6.18 进树的只是一个桩子：能探测、绑定、上电、问硬件信息、关机；一年后，随 7.3 合入的提交终于让它把 GPU 的微控制器跑起来，背后是 GEM 共享内存、页表管理、GPUVM 三套抽象先到位⁷。认亲成功只是开头，微控制器能跑起来，要等内存管理这几套依赖先齐——这正是延迟探测讲的那张依赖图，在真实驱动里长出来的样子。

同一批合并窗口里还有另一条线：英伟达 Nova 驱动在 7.4 合并窗口的改动里，加了一个向用户态上报 GPU 架构、芯片号与显存信息的 ioctl，转述自 Phoronix 对合并内容的报道⁸。用户态从此不只问“这块卡叫什么”，还能问“这块卡能干什么”。这一步很小，方向却对：认亲正在从认名字，往认能力挪。

落到原生 AI 操作系统，认亲该改成一张能力单。智能体要的不是驱动的名字，而是：多少向量阵列、显存带宽多少、支不支持稀疏与低精度、能不能切分给不同的智能体、固件与内存管理这些依赖齐了没有。绑定变成能力图的匹配：能力齐了才 probe，缺一项就 defer，并且说出缺的是哪一项，而不是静默失败或者硬上。旧抽象与新硬件的张力，在这里换了个样子：启动顺序是线性的叙事，硬件依赖却是一张图，延迟探测就是内核在线性叙事里给这张图留的口子；AI 时代的调度若还停留在按名字排队，就排不到能力本身。

言外之物也在这里。能力单由谁来写、由谁背书？Nova 的 ioctl 是驱动自己上报的，用户态只能信它报的；固件那一层仍不透明，微控制器里的东西并没有因此全部公开。上一期讲树里树外，讲的是代码住在哪棵树；这一期再往下问一层：能力描述住在哪一方的手里。主线审查能验代码，实测压测能验性能，但“这块卡到底能干什么”这句话的最终解释权，仍在写驱动与固件的那一边。认亲认到能力，下一层要认的，是背书。

三、先翻一张认亲表，再动手

手边任何一台 Linux 机器，不用动硬件，先把自家的认亲表翻出来：

ls /sys/bus/platform/devices/

ls /sys/bus/platform/drivers/

ls /proc/device-tree/

strings /proc/device-tree/compatible

第一条是平台总线上被发现的设备，第二条是已经注册的平台驱动，第三条是设备树的根目录，第四条读出整台机器在设备树根节点里报出的 compatible 字符串。再往深里走一层，挑一个平台设备，看它有没有绑上驱动：

ls -l /sys/bus/platform/devices/<设备名>/driver

有 driver 软链接，就是认领成功；没有，就是还没绑上，或者压根没有对得上的驱动。设备树在的机器上，还可以顺着 /sys/firmware/devicetree/base/ 找到这个设备对应的节点，对一下它的 compatible 是不是驱动匹配表里的那一串。再查一张延迟清单，看有没有设备还在等依赖：

cat /sys/kernel/debug/devices_deferred

这条要 debugfs 挂载且有权限才看得到，看不到也不必强求——没有这张表，本身也是一种答案：要么没有设备在等，要么这台机器没把这张表摊出来。今晚能动手的小实验，是把“等”看成一个可观察的状态：先记下几个平台设备绑的驱动名，再翻 dmesg 里 probe 失败又重试的痕迹，依赖齐了才绑上，这句话就不再只是概念。

落到日常的四种活，同一张认亲表有四种读法。一台跑本地模型的机器上，显卡驱动认亲走 PCI 枚举，报得出厂商号与设备号，难的是固件与内存管理这些依赖齐不齐；边缘盒上，大量外设走平台总线与设备树，板级描述错一行，摄像头或串口就认不上人；视频 AI 平台里，采集与编解码设备若在设备树里写错了中断或地址，视频流进来第一步就卡住；企业私有智能中心里，企业那一侧不直接碰驱动，但每一次“模型跑不动了”的报修，查到根上，先分一句是认亲没对上、还是依赖没等齐，再决定该改描述、等上游，还是自己动手。认亲这一步省不得，省了的系统，迟早要在别处连本带利还回来。

· · ·