第一次把编译好的 .ko 文件用 insmod 塞进 ARM 板子的内核，然后在 /dev 目录下看到自己的设备节点，再 echo 一个 1 进去，开发板上的 LED 真的亮了。那一刻应该是我做嵌入式这么久最踏实的成就感之一。这篇就聊聊我的第一个 ARM 板硬件驱动怎么写、怎么调、踩了什么坑，全过程记录，从框架概念到寄存器操作都会拆开讲。如果你学过单片机、刚入手 ARM Linux 开发板，或者正在准备嵌入式岗位面试，这篇应该能帮你把 Linux 驱动开发这条路的骨架捋顺。
先说明一下场景：我用的是一块 Cortex-A7 核的开发板，板子上跑的是 Linux，要驱动的硬件是最简单的 GPIO LED。驱动形态是内核模块，也就是 .ko 文件，不是单片机那种裸机寄存器操作，也不是 Keil + ARM Compiler 5 环境下的 STM32 点灯。这两个路线差的非常远，很多人一开始会把它们混在一起，后面会找个地方专门说清楚。
1. 动手前的整体思路：为什么第一个驱动选了“点灯”
1.1 先看一条用户命令在 Linux 里经历了什么
写驱动之前，我建议你先搞清楚一个问题：你在终端里敲下echo 1 > /dev/led这条命令，数据是怎么从用户态一路到硬件的。
/dev/led是一个设备文件，它对应着一个设备号。你往这个文件里写数据，内核虚拟文件系统（VFS）会先接管这次 write 操作，然后根据设备号找到对应驱动程序里注册的 file_operations 结构体，最终调用你在驱动里实现的led_write()函数。这个函数里写的代码，决定了一字节数据会被解释成“点亮 LED”还是“熄灭 LED”。
所以驱动在这个链条里干的事情很简单：承上启下。对上，它向内核注册一个“文件”接口；对下，它直接操作硬件寄存器，往 GPIO 的数据寄存器里写值，引脚电平就变了。你可以把驱动理解成一个翻译官，用户程序说的是“open/write/close”这种通用语言，硬件听的是“往这个内存地址写 1 或 0”这种寄存器指令，驱动就是那个两头通的中间人。
这就是我选点灯作为第一个驱动的根本原因：链路完整、结果直观。一个 LED 从暗到亮，意味着模块加载、设备注册、设备节点创建、file_operations 调用、寄存器操作这整条链路全部跑通了，这比写一个只打印日志的 hello_world 模块有说服力得多。灯亮了，你就知道你的驱动框架是活的。
1.2 板子和工具链怎么选，和单片机开发有什么不同
板子选型方面，我用的是一块以 IMX6ULL 为核心的学习板，Cortex-A7 内核，入门性价比很高。也可以用树莓派、瑞芯微 RK 系列或者全志的板子，思路完全一样，差别只在寄存器地址和复用配置。核心是你得拿到这个 SoC 的参考手册（datasheet）和对应的 Linux 内核源码树（kernel source tree），这两个是驱动开发的硬前提。
工具链这里有个非常大的分水岭：交叉编译。PC 上是 x86 架构，板子上是 ARM 架构，指令集不同，编译出来的程序不能直接混用。交叉编译的意思就是，在 x86 的 PC 上，用一套针对 ARM 的编译器，生成 ARM 上能跑的二进制。我的板子跑的是 32 位 ARM Linux，工具链前缀是arm-linux-gnueabihf-，如果你上的是 64 位系统，比如树莓派 4b 的 64 位镜像，那要换成aarch64-linux-gnu-。这两个前缀千万别搞混，进内核编译的时候 ARCH 参数也要对应：ARCH=arm对应 32 位，ARCH=arm64对应 64 位。
顺便说一下我从热词里看到好多人搜 “arm compiler 5.06”、“ARM Compiler 5”，那是 Keil MDK 里编译 Cortex-M 裸机代码的编译器，跟这里说的 ARM Linux 驱动交叉编译完全两码事。Cortex-M 系列跑的是裸机或者 RTOS，没有独立的 Linux 内核，驱动概念完全不同。你如果是从单片机转过来的，先把这个区别刻在脑子里，后面学习能少掉一层混乱。
还有个关键东西叫内核源码树。写内核模块，绝对不能直接引用你自己系统里的头文件，必须用目标板内核源码里的头文件。因为模块要和内核的接口保持一致，内核结构体变了、函数签名变了，你的模块就会编不过或者加载失败。这也是后面 Makefile 里 KDIR 参数要指向板子对应内核源码路径的原因。
2. 驱动框架拆解：模块、字符设备、寄存器操作
2.1 模块骨架：init、exit、printk 和加载生命周期
Linux 驱动最常见的形态就是可加载模块，编译出来是 .ko 文件。它和普通程序最大的区别是：没有 main 函数。模块的“入口”和“出口”是靠两个宏指定的：
static int __init led_init(void) { // 初始化代码 return 0; } static void __exit led_exit(void) { // 清理代码 } module_init(led_init); module_exit(led_exit); MODULE_LICENSE("GPL");__init和__exit这两个标记是有讲究的。__init表示这个函数只在加载阶段用一次，初始化完了之后，内核可以把这个函数占的内存直接释放掉，腾给别的地方。这个机制省内存，但你要是把运行期要用的逻辑也塞进__init函数里，改 bug 的时候会调得怀疑人生。
MODULE_LICENSE("GPL")不是随便写的。如果你声明了 GPL，内核里那些 EXPORT_SYMBOL_GPL 导出的符号才能用，比如很多内核 API。不声明或声明私有，加载时经常会遇到 “Unknown symbol” 的错误，这里面有知识产权因素的考虑，也有内核社区保证开源的意图。实际开发里直接写 GPL 就完事了。
模块里的打印不能用 printf，得用printk，比如：
printk(KERN_INFO "led driver init ok\n");printk 带日志级别，KERN_INFO、KERN_ERR、KERN_ALERT 这些。它输出到内核日志缓冲区，靠 dmesg 命令查看，而不是输出到终端。板子有串口的话，printk 的内容也会从串口 console 打出来，所以串口调试是嵌入式开发的底裤，接上 115200 波特率的串口线，什么内核日志都看得清清楚楚。调试的时候如果觉得日志级别不够，可以echo 8 > /proc/sys/kernel/printk，把所有级别全放开，不然低级别日志会被过滤掉，这也是我最早踩过的坑之一。
2.2 字符设备注册与设备节点的自动生成
我写的第一个正式驱动是字符设备驱动，也就是按字节流读写的那种，终端、GPIO、串口基本都是字符设备。字符设备在内核里有三套件：设备号、cdev 结构体、file_operations 操作表。
设备号是设备在内核里的“门牌号”，分主设备号和次设备号。主设备号区分驱动类型，次设备号区分同类型下的第几个设备。传统做法是自己指定一个主设备号，比如#define LED_MAJOR 240，然后用register_chrdev_region注册。但主设备号是有限资源，有冲突风险，现在更推荐动态分配：
dev_t devid; int ret = alloc_chrdev_region(&devid, 0, 1, "led");这个调用会让内核帮你挑一个空闲的主设备号，第一个次设备号是 0，数量是 1。
然后是 cdev：
struct cdev *led_cdev; led_cdev = cdev_alloc(); cdev_init(led_cdev, &led_fops); cdev_add(led_cdev, devid, 1);cdev_add就是把 cdev 对象挂到内核里。到这一步，内核已经知道这个设备存在了，但 /dev 下面还没有文件节点。
在旧的、简单的驱动里，你可以用device_create配合 class 让这个节点自动出现：
struct class *led_class; led_class = class_create(THIS_MODULE, "led_class"); device_create(led_class, NULL, devid, NULL, "led");class_create会在 /sys/class 下创建一个类目录，而用户态的 udev 或者嵌入式系统常用的 mdev 会监控内核事件，看到 device_create 之后就自动在 /dev 下创建对应节点，名字就是最后那个 “led”。这是现代 Linux 驱动推荐的玩法，开机后 /dev/led 自动出现，不需要手动 mknod。
注意一点：class 名字和设备节点名字别取重了。我刚开始图省事，class 叫 led，节点也叫 led，结果 /sys/class 下正常，但 /dev 节点就是不出来，后来才发现 class_create 的名字不能和同一子系统下其他设备重名，换个不冲突的名字就好了。
2.3 操作 ARM 寄存器：ioremap、GPIO 配置和 volatile
Linux 下的驱动不能像单片机裸机那样直接拿物理地址去访问。ARM 上开了 MMU，CPU 访问的是虚拟地址，物理地址要先映射成虚拟地址才能操作，这就是ioremap的用途：
#define GPIO1_BASE 0x0209C000 #define GPIO_DR 0x0000 #define GPIO_GDIR 0x0004 static void __iomem *gpio_dr; static void __iomem *gpio_gdir; gpio_dr = ioremap(GPIO1_BASE + GPIO_DR, 4); gpio_gdir = ioremap(GPIO1_BASE + GPIO_GDIR, 4);以我用的 IMX6ULL 为例，GPIO1 的寄存器基地址是 0x0209C000。数据寄存器 DR 偏移 0x00，方向寄存器 GDIR 偏移 0x04。要输出，得先在 GDIR 里把对应位写成 1；要拉高电平，就往 DR 的对应位写 1。
这里必须强调一个问题：驱动访问寄存器不要用普通的*(volatile unsigned int *)addr写法去猜，更不要用没加 volatile 的指针。寄存器是硬件状态，编译器不知道这块内存地址有“外部副作用”，优化的时候可能把两次读合并成一次，甚至把写操作优化掉。我记得第一次写的就是普通的*(unsigned int *)addr，结果怎么编译怎么不对，灯死活不亮，后来在内核文档里看到驱动访问寄存器应该用 ioread/iowrite 系列接口：
u32 val = ioread32(gpio_dr); val |= (1 << 21); iowrite32(val, gpio_dr);ioread32/iowrite32不只是读写，它们天然带内存屏障和 volatile 语义，编译器不会乱优化，CPU 也不会乱序执行到外部设备上，这是内核开发的标准姿势。强烈建议你从一开始就养成用 ioread/iowrite 的习惯，比手动加 volatile 更靠谱。
3. 第一版驱动从编码到运行：完整实操记录
3.1 完整代码与逐段解释
下面直接给出我第一版能跑的 LED 驱动代码，本意是做个教材级的参考。平台相关部分我按 IMX6ULL 写了注释，换成你自己的板子，核心逻辑完全通用。头文件里有一堆linux/xxx.h，这是内核模块必须包含的内核接口声明。
#include <linux/init.h> #include <linux/module.h> #include <linux/kernel.h> #include <linux/fs.h> #include <linux/cdev.h> #include <linux/device.h> #include <linux/uaccess.h> #include <linux/io.h> #define LED_GPIO_NUM 21 #define GPIO1_BASE 0x0209C000 #define GPIO_DR_OFFSET 0x0000 #define GPIO_GDIR_OFFSET 0x0004 static void __iomem *gpio_dr; static void __iomem *gpio_gdir; static dev_t led_devid; static struct cdev *led_cdev; static struct class *led_class; static int led_open(struct inode *inode, struct file *filp) { return 0; } static ssize_t led_write(struct file *filp, const char __user *buf, size_t count, loff_t *pos) { char kbuf; u32 val; if (copy_from_user(&kbuf, buf, 1)) return -EFAULT; val = ioread32(gpio_dr); if (kbuf == '1') val |= (1 << LED_GPIO_NUM); else val &= ~(1 << LED_GPIO_NUM); iowrite32(val, gpio_dr); return 1; } static struct file_operations led_fops = { .owner = THIS_MODULE, .open = led_open, .write = led_write, }; static int __init led_init(void) { int ret; ret = alloc_chrdev_region(&led_devid, 0, 1, "led"); if (ret < 0) return ret; led_cdev = cdev_alloc(); if (!led_cdev) goto err_unregister; cdev_init(led_cdev, &led_fops); ret = cdev_add(led_cdev, led_devid, 1); if (ret < 0) goto err_cdev_free; led_class = class_create(THIS_MODULE, "led_chardev"); if (IS_ERR(led_class)) { ret = PTR_ERR(led_class); goto err_cdev_del; } device_create(led_class, NULL, led_devid, NULL, "led"); gpio_dr = ioremap(GPIO1_BASE + GPIO_DR_OFFSET, 4); gpio_gdir = ioremap(GPIO1_BASE + GPIO_GDIR_OFFSET, 4); if (!gpio_dr || !gpio_gdir) { ret = -ENOMEM; goto err_device_destroy; } iowrite32(ioread32(gpio_gdir) | (1 << LED_GPIO_NUM), gpio_gdir); printk(KERN_INFO "led driver init ok, major=%d\n", MAJOR(led_devid)); return 0; err_device_destroy: device_destroy(led_class, led_devid); class_destroy(led_class); err_cdev_del: cdev_del(led_cdev); err_cdev_free: kfree(led_cdev); err_unregister: unregister_chrdev_region(led_devid, 1); return ret; } static void __exit led_exit(void) { iowrite32(ioread32(gpio_dr) & ~(1 << LED_GPIO_NUM), gpio_dr); iounmap(gpio_dr); iounmap(gpio_gdir); device_destroy(led_class, led_devid); class_destroy(led_class); cdev_del(led_cdev); kfree(led_cdev); unregister_chrdev_region(led_devid, 1); printk(KERN_INFO "led driver removed\n"); } module_init(led_init); module_exit(led_exit); MODULE_LICENSE("GPL");逐段说几个重点。
led_write里先调用了copy_from_user。为什么不能直接buf指针解引用？因为用户态传进来的指针指向的是用户空间的虚拟内存，驱动运行在内核态，不能假设那块内存已经映射到内核地址空间，直接访问很大概率 page fault 导致内核崩溃。这就是用户态和内核态之间的“隔离墙”，必须通过 copy_from_user/copy_to_user 拷贝。我听过有人为了偷懒用get_user替代，标准做法还是 copy_xxx_user，职责更明确。
led_open我留空了，只有返回值。说明驱动只需要支持 write，不需要在 open 里准备什么。但别删，因为 file_operations 里.open不写，用户 open 会失败。你可以试试不写 open 会怎样，会得到一个 ENODEV 的错误，这就是驱动的“菜单项”缺菜的结果。
led_write返回值我写了 1，表示成功消费一个字节。如果不写返回值，应用层 write 会认为写失败，shell 里 echo 甚至不会报错，但用 Python 或者 C 程序测试时返回值检查会失败。这种细节就是驱动和普通函数的差异：严格按内核调用约定返回。
3.2 Makefile 与交叉编译的实际细节
内核模块不能像普通程序那样 gcc 直接编译，需要一套专门的内核构建系统。Makefile 长这样：
obj-m := led_drv.o KDIR := /home/user/linux-imx PWD := $(shell pwd) all: make -C $(KDIR) M=$(PWD) ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- modules clean: make -C $(KDIR) M=$(PWD) ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- cleanobj-m := led_drv.o告诉内核构建系统，把 led_drv.c 编译成外部模块。KDIR是板子对应的内核源码树路径，这个源码树的版本和配置必须和板上运行的内核一致，不然模块可能加载失败。ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-是给编译器指定的，如果漏了 ARCH，make 会默认用本机 x86 内核头文件，编出来的模块一 insmod 就报版本不匹配。
编译好后在当前目录会生成 led_drv.ko。用file led_drv.ko看一下：
led_drv.ko: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV)看到 ARM 就对了。还可以用modinfo led_drv.ko查看模块信息，vermagic 字符串里能看到内核版本号和编译器版本，排查加载问题很有用。
把 .ko 弄到板子上，常见三种方式：SD 卡拷贝、NFS 网络共享、局域网 scp 传文件。开发调试阶段我强烈建议配一个 NFS 根文件系统，或者至少一个 NFS 目录，改完代码重新编译，板子上直接 mount 就能加载，不用反复插拔 SD 卡，效率差好几倍。
3.3 加载、亮灯、清理残留
板子起来之后：
insmod led_drv.ko然后看 /dev/led 是否出现。如果 udev/mdev 正常，会自动生成。没有的话手动创建：
cat /proc/devices | grep led mknod /dev/led c <主设备号> 0接下来试功能：
echo 1 > /dev/led # 灯亮 echo 0 > /dev/led # 灯灭如果灯能跟着 echo 的内容变化，恭喜，你的第一个 ARM Linux 驱动正式跑通了。但别高兴太早，灯亮了只是一半，还要验证卸载干不干净：
rmmod led_drv然后再次insmod led_drv.ko，能正常加载不报错，说明设备号、class、节点都释放干净了。这一步很关键，很多新手用的资源一个没清，第二次加载直接 cdev_add 失败，现象就是 insmod 没报错，但 /dev/led 不见了，因为设备号冲突或者 cdev 重复注册。我建议你在 led_exit 里严格按 init 的逆序释放，一个萝卜一个坑，这个习惯后来帮我避过很多雷。
4. 我在板上踩过的坑：现象、原因、解决办法
4.1 insmod 直接失败的典型报错
第一类常见坑是加载时报 Invalid module format。这时候先怀疑版本不匹配：你编译模块的内核源码树和运行时内核必须同版本同配置。用uname -r对比一下，再modinfo led_drv.ko看 vermagic。如果源码树版本号不对，换对应版本的分支重新编译即可。这种情况在拉取内核源码时很常见，看到仓库里有一样版本号的分支，但实际不上手，编完就翻车。
第二类常见坑是 Unknown symbol。如果模块里调用了某个内核函数，而这个函数没有 EXPORT_SYMBOL 导出给模块用，加载就会报这个。怎么查？看内核源码里对应函数前有没有 EXPORT_SYMBOL 或 EXPORT_SYMBOL_GPL。有些平台相关的 API 导出白名单限制，比如 gpiolib 有些函数只在特定配置下导出，配置没开也调用不了。
如果报错信息长了一串，教一个看报错的技巧：insmod报错后马上dmesg | tail -30，内核日志里会写明在哪个文件哪一行、符号名是什么。比如Unknown symbol led_fops，那多半是 file_operations 里某个函数指针的符号没配对，或者模块间依赖没加载。这个排查思路对任何内核报错都通用。
4.2 /dev/led 不出现的坑
module 加载成功但 /dev/led 没出现，原因一般集中在 device_create 和 udev/mdev 这两环。
先确认内核里 device_create 有没有被调用。printk 打印一下，或者在 led_init 里增加一个 “device_create called” 的日志。如果打印了但节点没出来，去看 /sys/class 下你的 class 目录里到底有没有 call 文件。如果 /sys 里也没有，那你可能压根没走到 device_create，或者 class_create 失败被 PTR_ERR 拦住了。
如果 /sys 里有设备，但 /dev 没节点，就是用户态设备管理器的问题。很多嵌入式系统没有完整 udev，用的是 busybox mdev，且需要启动时执行mdev -s扫描。如果板子没有配置 mdev 的 hotplug 规则，即使内核 event 发出去了，也没人处理。临时方案是手动 mknod；长期方案是检查系统启动脚本里有没有mdev -s。
另外还有一个权限的坑：节点出现了，但你 echo 的时候报 Permission denied。嵌入式板子默认 root 用户还好，但如果你的板子跑的是普通用户，需要 chmod 666 /dev/led，或者写 udev 规则。设备节点的权限归属也是嵌入式产品的一个大话题，涉及安全策略，普通学习阶段 chmod 先顶一下。
4.3 灯不亮：地址、复用、方向
这是最折磨人的一类问题，代码逻辑全对，但那个灯就是不给面子。拆开看，原因基本不出以下几类。
第一，GPIO 复用没有配置。大多数 SoC 的引脚不是生下来就是 GPIO，它默认可能接在 UART、I2C、PWM 或者其他外设功能上。你得在 IOMUX 寄存器里把该引脚设置为 GPIO 模式。以 IMX6ULL 为例，有 IOMUXC_SW_MUX_CTL_PAD_XX 和 IOMUXC_SW_PAD_CTL_XX 两组寄存器，前者选功能，后者配置上下拉和驱动能力。很多学习板出厂默认就是 GPIO 模式，所以你忽略这一块也能亮。但换一块板子、换一个引脚就不一定了，这是平台相关的重灾区，必须学会看数据手册里的引脚复用表。
第二，GPIO 外设时钟没使能。IMX6ULL 的 GPIO 控制器需要 CCM 时钟模块打开对应的 CCGR 位。它的时钟默认可能是关闭的，你要去 CCM_CCGR1 等寄存器里把 GPIO 模块的时钟打开。时钟没开的表现非常神奇：寄存器读出来全是 0 或者全是 f，写进去也没反应。我当时查这个查了很久，最后是拿着逻辑分析仪量引脚电平才发现的。Arm 的参考手册里 CCGR 位很多，一定要按 GPIO 控制器的编号找对。
第三，方向寄存器没写对。你配的引脚是输入方向，那么不管怎么往 DR 里写，引脚永远是外部输入的状态。正确流程是：先配置复用和时钟，再设置 GDIR 方向为输出，最后写 DR。顺序反了也会出现一时亮一时不亮的怪现象。
第四，位运算的边界问题。前面代码里我特意用了读改写方式：先 ioread32 读整个寄存器，改目标位，再 iowrite32 写回去。有些人图省事直接iowrite32(1 << 21, gpio_dr)，这会把其他 31 个 GPIO 引脚的数据全部清零。如果别的引脚在点灯前已经被 bootloader 或别的驱动设置了电平，这条代码一跑，整个 GPIO 组的输出全给你重置了。感觉像是“灯亮了但系统崩了”的诡异现象，就是这样来的。
4.4 调试与定位手段：dmesg、dump_stack、调用栈回溯
白板写代码能一次过的驱动我是没见过几个。遇到灯不亮，先不要到处改代码，先确认软件到硬件哪一环断了。
第一招是 dmesg。printk 的日志都在里面，dmesg | grep led立竿见影。但是 printk 也有个问题：数据量大了会刷屏，真正有用的信息被淹没掉。调试阶段可以把 printk 级别设为 KERN_ERR，或者临时加一些特征明显的字符串。
第二招是 dump_stack。在可疑函数里调用 dump_stack()，内核会打印当前的调用栈。这是在“某个函数有没有被调用”这个问题上最直接的证据。esp，当你在 file_operations 里写函数但用户程序死活调不进来时，dump_stack 能告诉你调用链到底走到哪一层。
第三招是看 Oops。内核出问题崩溃时那堆寄存器信息不是天书，里面最关键的是 PC、LR 两个寄存器。PC 是当前指令地址，LR 是函数返回地址。用arm-linux-gnueabihf-addr2line -f -e vmlinux 0x...把地址翻译成源码行号，就能定位到出错位置。这个技巧对 ARM 调用栈回溯特别有用，也是嵌入式面经里常考的 debug 能力。你可以打印出调用栈和寄存器快照，用scripts/decode_stacktrace.sh脚本处理，比人肉数行号快多了。
第四招才是硬件工具。万用表量引脚电平，逻辑分析仪看波形，示波器看时序。软件层面所有可能性排除之后，再上硬件工具。有个通用的排查顺序：代码逻辑、printk 路径、寄存器值、引脚电平、物理连接，一层层切断，永远不要跳过前面的步骤直接怀疑硬件。
5. 驱动这条路，过了“点灯”之后往哪走
5.1 让代码更“现代”：设备树和 platform 驱动
点灯驱动验证了框架，但它有个硬伤：硬件信息是写死在代码里的。你换一个 GPIO 号，就要改代码重新编译。这在开发板学习阶段可以接受，到了真实产品和内核社区的正统玩法，这种做法基本就是异端。
现代 ARM Linux 驱动的主流形态是 platform 驱动配合设备树。硬件信息通过设备树节点描述，比如：
led { compatible = "mycompany,led"; reg = <0x0209c000 0x10>; gpios = <&gpio1 21 GPIO_ACTIVE_HIGH>; };驱动里用of_property_read_u32等接口去匹配和读取这些属性。probe 函数在设备节点匹配时被自动调用。这样同一份驱动可以适配多个平台，换硬件描述改设备树就行。这个演进方向建议你一定要走一遍，它是后续几乎所有复杂驱动的基础。
5.2 从输出到输入：按键、中断、读写接口
点灯只用了 write 方向。再加一个按键，用中断方式检测，你就能把 read 方向也打通了。核心是 request_irq 注册中断处理函数，中断里用 workqueue 或者 tasklet 处理真正的工作，然后通过 copy_to_user 把按键状态送出去。这样驱动就从一个“只会被写”的设备，变成了“能读能写”的双向设备。
加上 read 之后，自然要处理阻塞、非阻塞和 poll 的问题。用户空间 read 没数据的时候是挂起等还是立刻返回？驱动里怎么实现 wait_event_interruptible？这些都是驱动工程师面试的常客，也是从点灯到真实设备驱动的必然台阶。再往后就是 ioctl 接口、异步通知、DMA 传输、内核中的并发与锁，每个方向挖下去都是深坑。
我个人在写了几个字符设备之后的最大体会是：驱动开发真正的难点不是那几十行 C 代码，而是理解内核的模型。你写的每个接口函数，并不是孤立存在的，它要遵守 VFS、设备模型、中断子系统、并发控制等一整套规格。看懂内核文档里 Lifecycle、Data Types 这些章节，比背一万行代码都管用。
最后分享一个我自己的小习惯吧：我把第一个驱动成功点亮那年记在代码开头注释里，之后每次换新平台、新内核版本，第一件事就是把点灯驱动重新移植一遍。它就像一个冒烟测试，能最快告诉你工具链对没对、内核源码树匹配不匹配、设备模型改成了什么样。驱动这条路很长，但点灯这第一个台阶，值得你踩稳了再往上走。