用"假"驱动读懂真内核：linux-dummy-drivers 仓库解读

学习 Linux 驱动开发最大的障碍往往不是代码本身，而是没有硬件。写 I2C 驱动需要一块传感器，写 DRM 驱动需要一块 LCD 屏，写 V4L2 驱动需要一台摄像头——而 linux-dummy-drivers 这个仓库正是为此而生：它用一套"假"驱动，把内核各子系统的真实骨架完整地搭了出来，让学习者在纯软件环境下就能把每个子系统摸透。

一、仓库是什么

这是嵌入式工程师 IotaHydrae（Hua Zheng，来自 embeddedboys）维护的一个 Linux dummy drivers 合集。所谓 dummy driver，就是用代码"扮演"一块硬件、但背后没有任何真实硅片的驱动程序。仓库的目标写得很直白：

These drivers are designed with reduced complexity to simulate various hardware components and are intended for learning purposes. With this repository, you can easily understand how the driver works when invoked from userspace tools. It is a good starting point if you want to develop an actual hardware driver.

即：降低复杂度、模拟硬件、面向学习。作者在 WSL2 环境（Ubuntu 24.04.3，内核 6.6.114.1-microsoft-standard-WSL2+）上完成了全部验证——也就是说，一台没有开发板的普通 PC 就能完整复现这些实验，仓库还维护着 7.0.0-28-generic 与 rpi-6.12.y 分支，适配不同内核版本。

二、仓库总览

整个仓库约 2700 行 C 代码，按子系统分目录，每个目录自带 README、Makefile 和验证脚本，覆盖了从"三行 Hello World"到"运行时修改机器码"的完整梯度：

开发状态：v4l2、fbdev、drm_simple_pipe、i2c adapter、spi master、gpiochip 已完成；usb host、sound、dma engine 仍在 TODO 中——这也暗示了这套方法论完全可以继续复制到更多子系统。

三、从最小的开始：hello 与 template

hello/ 只有 20 行，是标准的 module_init / module_exit 骨架，适合第一次 insmod 的仪式感。

真正有"工程感"的是 template/，它把字符设备驱动的固定套路提炼成了 66 行模板：

alloc_chrdev_region(&template->dev_num, 0, 1, "dummy-template");
template->class = class_create("dummy-template-class");
template->dev  = device_create(template->class, NULL, template->dev_num, NULL, "dummy-template-dev");
/* subsys alloc & register */

register 失败时从 device_destroy → class_destroy → unregister_chrdev_region 逐级回滚，错误处理路径清晰，还预留了 /* subsys alloc & register */ 注释位。作者的用法是：

cp template -rd static_call   # 复制后全局替换字符串即可

regulator 驱动就是这么从模板长出来的——先有骨架，再填子系统 API，这正是 dummy 方法论的精髓。

四、理解内核的设备模型：bus/basic_bus 与 bus/dummy_bus

设备模型（driver model）是内核驱动架构的基石，但直接读 drivers/base/ 源码很容易迷失。bus/basic_bus 把整个流程压缩到 139 行，加载后的日志就是最生动的教材：

[  +0.000488] dummy-bus, dummy_bus_init: bus registered
[  +0.000505] dummy_device_init, device registered
[  +0.000728] dummy-bus: match(dummy0 <-> dummy0)
[  +0.000525] dummy_driver_probe
[  +0.000295] dummy_driver_init, driver registered

注册 bus → 注册 device → bus 遍历匹配 → 命中后调用 driver 的 probe，一条完整链路肉眼可见。

bus/dummy_bus 更进一步，回答了一个新手最容易困惑的问题：为什么平台、SPI、I2C、PCI、USB 各有一套 device/driver 类型，而不是共用 struct device？ 因为 SPI 需要存片选号、模式、频率、bits_per_word，这些信息没有地方放。答案是在 C 语言里用组合模拟继承：

struct platform_device { ...struct device dev; };
struct spi_device     { ...struct device dev; };
struct i2c_client     { ...struct device dev; };

struct device 就是所有总线设备的"基类"。看懂这段，再回看内核源码里的各种 container_of，一切就顺理成章了。

五、看得见的显示：fbdev 与 drm

显示子系统的痛苦在于：没有屏幕就什么都验证不了。这个仓库用两种方式解决了。

fbdev（336 行）：dummy-fb.c 注册一个传统帧缓冲，在 PC 上会出现在 /dev/fb1。用 fbcat 截图：

sudo ./fbcat /dev/fb1 > screenshot.ppm
sudo ./fbgrab -d /dev/fb1 output.png

DRM（355 行）：基于 drm_simple_display_pipe，加载后生成一个 480x320 的 fb，并通过 drm_atomic_helper_damage_merged 把脏区域打印出来——这是学习 DRM 损伤追踪（damage tracking）的绝佳入口：

[ 1165.018451] dummy-drm: dummy_drm_pipe_update
[ 1165.018454] dummy-drm: x1: 184, y1: 48, x2: 192, y2: 64

当你在终端里移动鼠标时，dmesg 里就能看到屏幕上哪个矩形区域被重绘。一个假的 pipe 函数，把 atomic 提交、plane 状态、framebuffer 的生命周期全部串了起来，还能 make dump 用 netpbm 把显存导成 PNG。

六、能"造假"外设的总线：i2c 与 spi

I2C：i2c.c 注册一个假 adapter，配好用户态验证链：

sudo modprobe i2c-dev
sudo insmod dummy_i2c.ko
i2cdetect -l        # 看到 dummy_i2c bus0
sudo i2cdetect -y 0 # 扫描出 0x08 ~ 0x77 全部地址
echo eeprom | sudo tee /sys/bus/i2c/devices/i2c-0/new_device

i2cdetect -y 0 扫出一整排地址的那一刻，I2C 的"控制器—总线—从设备"三层模型瞬间具象化。README 还顺手记录了内核里 no algo supplied 的校验逻辑位置（drivers/i2c/i2c-core-base.c），把异常路径也变成了学习材料。

SPI：假 master 注册后，用 driver_override 把用户态 spidev 绑上去：

echo spidev | sudo tee /sys/bus/spi/devices/spi0.0/driver_override
echo spi0.0 | sudo tee /sys/bus/spi/drivers/spidev/bind

tests/spi-test 直接对 spidev 做读写，验证整条链路。

七、让工具链跑起来：gpio、regulator、firmware

这三个驱动展示了一个共同哲学：dummy driver 要让真实用户态工具能"端到端"工作。

gpio：注册一个 16 路的 gpio_chip，get / set / request / free / direction_input / direction_output 全部实现——而每个回调函数体只有一行 dev_info(..., "%s", __func__)。当你用 libgpiod 或 sysfs 操作 GPIO 时，dmesg 里会依次打印出内核到底调用了哪些回调、以什么顺序调用。这就是 dummy driver 最核心的价值：把内核与驱动之间的每一个握手都变成可见的日志。

regulator：一个 regulator.c（provider）+ 一个 consumer.c（consumer），演示了 regulator 框架"请求—获取—使能—调压—释放"的完整生命周期，而消费端只需要 74 行。

firmware：fw.c 调用 request_firmware()，配合 dynamic debug 打开 drivers/base/firmware_loader/* 的日志，能看到固件加载器按 /lib/firmware/updates/ → /lib/firmware/ → .xz 压缩包的顺序逐一尝试的完整搜索路径，连"找不到文件"的失败路径都成了教学素材。

八、进阶：static_call 深度笔记

仓库里最"硬核"的一篇是 static_call/ 的 README，它已经不满足于"模拟硬件"，而是把 static_call 这个内核机制本身讲透了：函数指针灵活但间接跳转贵，普通调用快但不能换实现，static_call 用"启动时编成普通 call，运行时改写 call 目标机器码"来兼得两者。文中附上了 objdump 反汇编，展示 __SCT__dummy_static_call 里的 jmp 指令如何在 static_call_update() 之后被改写、.static_call_sites ELF section 如何记录每个调用点，并对比了 trampoline 与 inline 两种实现。

这也展示了 dummy driver 的另一个用法：当你想搞懂某个内核机制，就写一个最小的 dummy 模块去触发它，然后用观测工具把机制本身"照"出来。

九、为什么 dummy driver 能帮你理解一个子系统

归结起来，这个仓库的方法论可以总结为四点：

1. 1. 剥离硬件，聚焦 API。真实驱动的代码量里，硬件时序、寄存器操作、中断底半部往往占去八成，剩下两成才是子系统 API。dummy driver 砍掉那八成，剩下的就是子系统的"纯骨架"——drm_simple_pipe 五个回调、gpio_chip 六个 ops、vb2_queue 四个流程，一眼看尽。
2. 2. 全链路可观测。每个回调都打日志，配合 dmesg 就能"看见"内核的调度：用户态工具敲一下，内核调用了哪个函数、传了什么参数、按什么顺序执行，全部透明。这比读一百篇博客都直观。
3. 3. 端到端打通用户态。i2cdetect、cheese、fbcat、libgpiod、spidev——这些真实工具全部可以驱动 dummy 硬件。你学会的不只是"怎么写驱动"，而是"驱动在系统里如何被使用"，这才是完整的学习闭环。
4. 4. 可演进为真实驱动。作者自己的 i2c-suniv（Allwinner suniv SoC 的 I2C adapter）就是这条路径的实证：dummy 验证框架 → 替换为真实硬件操作 → 变成能跑的产品驱动。dummy 不是终点，是起点。

十、上手建议

建议按这个顺序读：

1. 1. hello → template：建立最小模块的直觉；
2. 2. bus/basic_bus → bus/dummy_bus：搞懂设备模型；
3. 3. 挑一个你正在用的子系统深入：做显示的读 fbdev / drm，做嵌入式的读 i2c / spi / gpio；
4. 4. 用 make test 复现日志，再对照内核源码（仓库 README 已经标好了对应源码位置）；
5. 5. 最后尝试用 template 复制出自己的第一个 dummy driver。

唯一的门槛是环境：需要一份可加载模块的内核（WSL2 或任意发行版均可），clone 下来 make 就能跑。

结语

Linux 内核的复杂之处，从来不是某个子系统本身，而是它被埋藏在庞大工程代码中的调用关系。linux-dummy-drivers 用"假硬件"换来了"真可见"，把内核与驱动之间的每一次握手都摆在台面上。对初学者，它是一条加速理解子系统的最短路径；对老手，它是快速验证某个子系统行为的脚手架。下次想搞懂某个子系统时，不妨先问自己一句：能不能先写一个 dummy 驱动，把它"假"出来？