做Linux内核驱动开发这件事，很多从应用层转过来的开发者第一个月基本都在跟“为什么我的模块一加载就死机”较劲。说实话，内核开发和普通应用开发是完全不同的两种思维方式：应用层写崩了顶多报个段错误，在内核里写崩了直接整机宕机，连日志都来不及看。这篇文章主要围绕我在实际项目中摸爬滚打的经历，把字符设备、platform总线、设备树、并发同步、中断与内存管理这些绕不开的技术核心梳理一遍，也会分享一些踩坑之后才明白的教训。想入坑内核驱动、或者已经写了几年驱动但总觉得底子不够扎实的开发者，这篇文章值得花点时间认真读一遍。

1. 驱动开发前必须想明白的事

1.1 内核态和用户态的本质差异

写驱动之前，先搞清楚驱动代码运行在什么环境里。内核态代码拥有最高权限，可以访问所有内存地址、操作所有寄存器，但也意味着没有任何保护机制。空指针解引用在用户态是一个可以捕获的信号，在内核态里就是一次oops或者直接死锁。

另外一个容易忽略的点是内核态不能随便调用用户态的库函数。你习惯的printf、malloc、strcpy这些，内核里都有对应的替代品：printk对应printf，kmalloc对应malloc，strlcpy/strscpy对应strcpy。很多新手驱动写多了，在中断处理函数里直接调用printk刷日志，结果系统延迟飙到不可用——printk在中断上下文里并非完全禁止，但大量输出会严重影响实时性。

从应用开发转过来的朋友，我建议先记住三个原则：

• 内核代码出错没有“重试”机会，必须保证每个分支都安全
• 用户态传过来的任何数据都不可信，必须用copy_from_user校验
• 能不用锁就不用锁，能用原子变量就不用自旋锁，能用自旋锁就不用互斥锁

1.2 驱动框架选型决定工作量

Linux内核支持三类主流驱动框架：字符设备、块设备、网络设备。绝大多数硬件（传感器、GPIO控制器、I2C/SPI设备、显示控制器等）都能归类到字符设备。块设备主要面向存储类硬件，网络设备面向网卡这类数据包收发场景。

选择驱动框架的时候，需要想清楚硬件的本质通信方式。比如一个温度传感器，通过I2C总线读取数据，用户程序想要的是“给我当前温度值”，这就是典型的字符设备。而一个eMMC存储芯片，用户程序要的是读写数据块，这就是块设备。选错了框架，后面整个架构都要推倒重来。

模块化驱动的加载机制也很重要。先看一个最简单的模块代码：

#include <linux/init.h> #include <linux/module.h> static int __init demo_init(void) { printk(KERN_INFO "demo module loaded\n"); return 0; } static void __exit demo_exit(void) { printk(KERN_INFO "demo module unloaded\n"); } module_init(demo_init); module_exit(demo_exit); MODULE_LICENSE("GPL"); MODULE_AUTHOR("developer"); MODULE_DESCRIPTION("A simple demo driver");

这里有几个细节容易被忽略。MODULE_LICENSE("GPL")不只是法律声明，内核里有大量EXPORT_SYMBOL_GPL符号，如果你的模块不声明GPL，这些接口根本链接不了。我遇到过模块编译通过但insmod时说“Unknown symbol”的情况，查了半天最后发现是license声明问题。

__init和__exit宏也不只是为了好看。带有__init标记的函数在初始化完成后，其占用的内存可以被释放回收。如果初始化函数写得太臃肿，加载完之后这部分内存白白浪费。ARM平台上内核映像通常只有几十MB，能省一点是一点。

2. 字符设备驱动的骨架与关键实现

2.1 设备号与cdev注册

字符设备是入门核心，它的结构其实非常简单，但每一步都有坑。一个完整的字符设备驱动包括：分配设备号、初始化cdev、填充file_operations结构体、创建设备节点。

设备号由主设备号和次设备号组成。主设备号标识驱动类型，次设备号标识同类型下的不同设备。分配方式有静态和动态两种：

// 静态分配 int register_chrdev_region(dev_t dev, unsigned int count, const char *name); // 动态分配 int alloc_chrdev_region(dev_t *dev, unsigned int baseminor, unsigned int count, const char *name);

主设备号虽然是0-4095的范围，但静态指定要特别小心，需要先查内核文档里哪些号已经被占用。实际操作中我更推荐动态分配，因为省心且不会冲突。通过cat /proc/devices可以查看到当前系统里已经注册的设备号和对应驱动名。

获得设备号之后，需要用cdev结构体把设备和操作函数绑定起来：

struct cdev *cdev_alloc(void); void cdev_init(struct cdev *cdev, const struct file_operations *fops); int cdev_add(struct cdev *cdev, dev_t dev, unsigned count);

这里最容易被忽略的是cdev_add之后设备就“活了”，内核随时可能调用你注册的open/read/write回调。如果此时设备还没有完全初始化（比如寄存器还没配置、缓冲区还没分配），系统崩溃概率极高。正确的顺序是：先完成硬件初始化、再注册中断、最后cdev_add。

2.2 file_operations回调函数的坑

file_operations是字符设备驱动的灵魂，它定义了一个用户程序打开设备节点后可以执行的所有操作。核心回调包括open、release、read、write、unlocked_ioctl、mmap。

新手写read和write时最常见的错误是没处理“返回部分数据”的情况。用户调用read(fd, buf, 1024)，你的驱动可以不一次性返回1024字节，可能只返回64字节。用户层会自己循环读取。但如果你的驱动return -1而不带任何错误码，用户层就永远不知道发生了什么。

正确的做法是：

static ssize_t demo_read(struct file *filp, char __user *buf, size_t count, loff_t *ppos) { size_t bytes_to_copy; char kernel_buf[64]; bytes_to_copy = min(count, sizeof(kernel_buf)); /* 填充kernel_buf，比如从硬件寄存器读取数据 */ if (copy_to_user(buf, kernel_buf, bytes_to_copy)) return -EFAULT; return bytes_to_copy; }

copy_to_user是另一个高频出错点。内核空间的指针不能直接传给用户空间，必须通过copy_to_user/copy_from_user拷贝数据。这个函数会检查目标地址的合法性，而且在拷贝期间如果发生页面错误，会返回未拷贝的字节数。返回非零值说明拷贝失败了。

另一个经常被忽略的是file_operations里的open回调。用户每次open设备节点都会触发它，如果驱动里有全局状态（比如设备是否已被占用），需要在open里用原子操作或互斥锁保护。我见过一个驱动，两个进程同时打开设备节点，因为open里没做互斥，结果两个进程都在操作同一个硬件寄存器，整个输出数据全乱了。

2.3 使用miscdevice简化注册流程

如果你只是写一个简单的驱动，不希望处理主设备号分配、cdev管理、类创建这些繁琐步骤，可以用miscdevice这个便捷框架。它本质上还是字符设备，但内核帮你把设备和/dev节点都处理好了。

#include <linux/miscdevice.h> static struct file_operations demo_fops = { .owner = THIS_MODULE, .open = demo_open, .read = demo_read, }; static struct miscdevice demo_miscdev = { .minor = MISC_DYNAMIC_MINOR, .name = "demo_dev", .fops = &demo_fops, }; module_init(demo_init); module_exit(demo_exit);

miscdevice会自动在/dev下创建名为demo_dev的设备节点，不用写class_create和device_create。对学习阶段和原型验证阶段来说非常方便，直接定位到快速实现功能。但代码规模变大后，建议还是回到标准字符设备流程，因为miscdevice的管理粒度比较粗，设备数量多的时候会占用过多动态次设备号资源。

3. 从硬编码走向platform驱动与设备树

3.1 为什么需要platform总线

早期的ARM Linux驱动里，硬件资源信息（寄存器地址、中断号、时钟频率）都硬编码在驱动代码里。板子一换，代码就要重新编译。这种模式在设备少、平台单一的时候还行，但现代SoC外设那么多，代码会变成一团乱麻。

platform总线就是来解决这个问题的。它把“设备是什么”和“驱动怎么工作”分离开来。设备侧描述硬件资源的信息放在platform_device里，驱动侧处理逻辑放在platform_driver里，内核的platform总线负责把两者匹配起来。

再用设备树之后，platform_device通常由设备树节点自动生成。驱动侧只需要写platform_driver，匹配成功后从device_node里读取寄存器地址、中断号等资源即可。这样一来，同一份驱动代码可以用在不同板卡上，只要设备树描述正确就行。

3.2 of_match_table与probe流程

一个标准的platform驱动长这样：

static const struct of_device_id demo_of_match[] = { { .compatible = "vendor,my-device", }, { } }; static int demo_probe(struct platform_device *pdev) { struct resource *res; void __iomem *base; int irq; res = platform_get_resource(pdev, IORESOURCE_MEM, 0); base = devm_ioremap_resource(&pdev->dev, res); if (IS_ERR(base)) return PTR_ERR(base); irq = platform_get_irq(pdev, 0); /* ... */ return 0; } static struct platform_driver demo_driver = { .probe = demo_probe, .remove = demo_remove, .driver = { .name = "demo-driver", .of_match_table = demo_of_match, }, }; module_platform_driver(demo_driver);

compatible字符串是设备树节点里的compatible属性和驱动里的of_device_id进行匹配的关键。它通常采用“厂商名,设备型号”的格式，比如“ti,am3358-adc”。匹配成功之后，内核会调用驱动的probe函数，驱动在这里完成硬件初始化和资源申请。

module_platform_driver是个很实用的宏，它自动展开为module_init和module_exit，省去一堆样板代码。

3.3 设备树语法与常见解析接口

设备树（Device Tree）是一种描述硬件资源的树形数据结构。以一个简单的I2C设备为例：

&i2c0 { status = "okay"; clock-frequency = <400000>; temp_sensor@48 { compatible = "vendor,tmp451"; reg = <0x48>; interrupt-parent = <&gpio2>; interrupts = <14 IRQ_TYPE_EDGE_FALLING>; }; };

驱动里解析设备树属性的API族非常庞大，我建议先掌握这几个：

• of_find_node_by_name / of_find_node_by_compatible：寻找节点
• of_property_read_u32 / of_property_read_string：读取标量属性
• of_get_named_gpio / gpiod_get：获取GPIO
• of_irq_get / platform_get_irq：获取中断号

一个常见问题：设备树属性读不到时，probe函数返回什么？返回值最好是负数错误码，比如-ENODEV、-EINVAL。返回0表示成功，如果后续代码因为某个关键资源缺失无法继续工作，最好明确返回-EINVAL，这样probe失败的内核日志会提示你哪里出了问题。

我自己的习惯是，probe函数里每一步资源获取都检查返回值并打印清晰的错误上下文日志。调试设备树解析问题时，这些日志比猜测硬件问题高效得多。比如：

res = platform_get_resource(pdev, IORESOURCE_MEM, 0); if (!res) { dev_err(&pdev->dev, "failed to get MEM resource\n"); return -ENXIO; }

dev_err打印出来的信息会带设备名和具体location，配合dmesg一眼就能定位问题。

4. 并发与同步：驱动里锁的取舍

4.1 锁选型：自旋锁、互斥锁还是原子变量

驱动开发绕不开并发问题。硬件中断、内核线程、用户进程都可能同时进入驱动代码路径。选择锁类型要看你所在的环境能不能安全地睡眠。

自旋锁（spinlock）适合在原子上下文中使用，比如中断处理函数。它获取锁的时候如果锁被占用，会原地忙等，不会睡眠。代价就是CPU空转，长时间持锁会拖慢整个系统。所以自旋锁的临界区必须短，不能有kmalloc、copy_to_user这类可能睡眠的操作。

互斥锁（mutex）适合在进程上下文中使用，获取不到锁时可以睡眠等待，不会浪费CPU。代价是持锁期间不能中断，不适合在中断上下文里使用。

原子变量（atomic_t）则是最轻量的方案，适合单纯计数或置位的场景。很多新手一开始就上自旋锁，其实读多写少的场景用seqlock或RCU可能性能更好，但复杂度也会上升。

锁选型决策表（推荐保存）：

4.2 锁的使用场景与死锁演练

我给大家模拟一个最常见的死锁场景。驱动里有两个资源A和B，进程1先锁A再锁B，进程2先锁B再锁A。如果两个进程同时执行，就会出现死锁：进程1持有A等待B，进程2持有B等待A，谁都释放不了。内核检测到死锁会打印“BUG: soft lockup”或者触发hung task检测，但那时候系统基本已经不可用了。

避免死锁的方法有几个：

• 保持统一的锁获取顺序。比如全局约定“先锁A后锁B”，所有路径都遵守
• 使用mutex_trylock而不是mutex_lock，获取不到锁时返回错误而不是死等
• 使用锁的嵌套层次时要特别小心，中途不要释放后又重新获取

我在项目里遇到过一种隐蔽的死锁：一个驱动在ioctl里同时调用另一个驱动，两个驱动对同一个寄存器组操作，各自都持有锁。一个进程通过ioctl A进入第一个驱动，等锁B；另一个进程通过ioctl B进入第二个驱动，等锁A。两边都死等。这个问题最后通过合并锁粒度解决的，把两个驱动共享的寄存器组统一用一个全局锁保护，不再各自管理锁。

4.3 关中断与local_irq_save的必要性

进程上下文访问共享数据时，一个很小的窗口可能导致bug：进程正读一个32位寄存器，突然来了一个中断，中断里也读这个寄存器。如果进程上下文操作不是原子的，就可能读到半个旧状态。

解决办法是获取自旋锁的同时关中断。spin_lock_irqsave会保存当前CPU的中断状态并关中断，spin_unlock_irqrestore恢复之前的状态。注意不能用spin_lock_irq，因为它只关中断不保存状态，如果函数返回之前中断本来就是关闭的，释放锁后中断会意外打开，破坏之前的中断状态。

对绝大多数场景，建议统一用spin_lock_irqsave/spin_unlock_irqrestore。虽然有个别情况可以用基础版本，但用错了很难排查，不如一开始就按最严格的方式写。

5. 内存与中断管理的实战细节

5.1 内核内存分配接口

内核提供了多个内存分配接口，每个都有适用场景：

• kmalloc：分配物理连续内存，适合DMA传输的缓冲区、与硬件直接交互的数据结构
• vmalloc：分配虚拟连续内存，物理内存可以不连续，适合大块内存但不需要DMA的场景
• kzalloc：kmalloc + 清零，避免使用未初始化内存
• devm_kzalloc：带设备生命周期管理的版本，设备销毁时自动释放，减少内存泄漏遗漏

选择原则其实很简单：硬件要的还是驱动自己要的。硬件需要总线地址（DMA），就必须用kmalloc；驱动自己维护一个大缓存，vmalloc就够了。另外千万别把kmalloc分配的地址直接给硬件做DMA，因为kmalloc虽然物理连续，但不能保证是IOMMU需要的总线地址连续。正确的做法是用DMA API，比如dma_alloc_coherent。

5.2 中断处理：顶半部与底半部拆分

中断处理不只是注册一个handler那么简单。中断处理函数执行时，当前CPU是不知道其他任务的，如果handler里做太多事，比如等待硬件操作完成、copy_to_user、睡眠，系统直接卡死。

正确做法是把工作拆分成两部分：

• 顶半部（硬中断）：快速响应硬件事件，读取/清除中断状态寄存器，把需要延迟处理的数据放入队列，然后return IRQ_WAKE_THREAD或者触发软中断
• 底半部（软中断/工作队列/线程化中断）：执行真正耗时的操作，比如数据处理、唤醒用户空间进程

Linux提供了多种底半部机制。对初学者最推荐的是threaded irq（线程化中断），它允许中断处理函数在一个内核线程中被调用，可以直接在里面睡眠。

static irqreturn_t demo_irq_handler(int irq, void *dev_id) { /* 快速处理：读取硬件状态，禁止当前中断 */ disable_irq_nosync(irq); schedule_work(&work); /* 或者 wake_up_interruptible */ return IRQ_HANDLED; } static irqreturn_t demo_irq_thread(int irq, void *dev_id) { /* 慢速处理：在这里做耗时的操作 */ return IRQ_HANDLED; } request_threaded_irq(irq, demo_irq_handler, demo_irq_thread, IRQF_TRIGGER_FALLING, "demo_irq", dev_id);

这里用dev_id参数可以支持多个设备共享同一个中断号。不同的注册者通过dev_id来区分是哪个设备触发的中断。free_irq时也要传入相同的dev_id，否则内核会报错。

5.3 阻塞IO与等待队列

用户程序下发的read调用，硬件数据可能还没准备好。这时候驱动可以选择返回-EAGAIN让用户忙等待，也可以选择睡眠等待数据就绪后被唤醒。睡眠等待是更合理的做法，实现方式就是用等待队列。

static DECLARE_WAIT_QUEUE_HEAD(demo_wq); static ssize_t demo_read(struct file *filp, char __user *buf, size_t count, loff_t *f_pos) { wait_event_interruptible(demo_wq, demo_data_ready); /* 数据就绪，拷贝到用户空间 */ if (copy_to_user(buf, &demo_val, sizeof(demo_val))) return -EFAULT; return sizeof(demo_val); } static irqreturn_t demo_irq_handler(int irq, void *dev_id) { demo_data_ready = 1; wake_up_interruptible(&demo_wq); return IRQ_HANDLED; }

每次中断来了把标志位置位，唤醒睡眠的读进程。用户层表现得就像“传感器数据一到，read立即返回”。不过需要注意wait_event_interruptible是可能被信号的，返回非零值说明被信号中断，驱动需要返回-ERESTARTSYS让用户层重试这次系统调用。

实际调参时，read睡眠到返回的延迟、中断唤醒的抖动这些都是需要重点测试的项目。我在做一个定时器驱动时，发现中断里wake_up_inturruptible有时候会被优化得不及时，后来在唤醒前加了一个smp_wmb()保证写操作先于唤醒，解决了数据还没写就看到标志位变化的问题。

6. ioctl与用户空间交互的最后一块拼图

6.1 ioctl命令编码规则

很多硬件功能用read/write表达不了——设置采样率、开始/停止采集、修改工作模式。这些可以全部通过ioctl实现。ioctl的三要素是命令号、参数类型指针、数据的读写方向。

命令号按Linux内核标准用_IO/_IOR/_IOW宏生成：

#define DEMO_IOC_MAGIC 'D' #define DEMO_IOC_SET_SAMPLERATE _IOW(DEMO_IOC_MAGIC, 0x01, int) #define DEMO_IOC_GET_STATUS _IOR(DEMO_IOC_MAGIC, 0x02, struct demo_status) #define DEMO_IOC_RESET _IO(DEMO_IOC_MAGIC, 0x03)

第一参数是幻数，通常在1-255之间。第二参数是命令序号，同一驱动的命令直接尽量不重叠。最后一个参数是数据类型，内核用它来检查传入/传出的缓冲区大小，防止越界。

实现ioctl时注意，用户传入的指针不能直接解引用，必须用copy_from_user/copy_to_user：

static long demo_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) { int ret = 0; switch (cmd) { case DEMO_IOC_SET_SAMPLERATE: { int rate; if (copy_from_user(&rate, (int __user *)arg, sizeof(rate))) return -EFAULT; /* 配置硬件采样率 */ ret = demo_set_rate(rate); break; } case DEMO_IOC_GET_STATUS: { struct demo_status st; /* 填充st */ if (copy_to_user((void __user *)arg, &st, sizeof(st))) return -EFAULT; break; } default: return -ENOTTY; } return ret; }

6.2 错误码返回与用户空间的errno

驱动返回-1时，用户空间的perror会显示错误码信息。Linux内核约定负数的errno，正数则会被当作成功。这里非常容易搞混：驱动return -EINVAL，对应用户态的errno=22，perror打印“Invalid argument”。如果驱动错误地返回了EINVAL（正数），用户态会把它当成成功，读出来的数据都是错误码，问题排查起来异常痛苦。

另外，_IO/_IOR/_IOW还有对应的_IOWR命令，表示双向传输。这个一定要准确选择，因为内核会通过它判断用户缓冲区的访问权限。如果你的命令实际要写回数据却只声明了_IOW，内核因为检测到写操作而未授权，会直接返回EFAULT。

7. 调试经验与常见故障排查实录

7.1 dmesg与printk动态调试

驱动开发的核心调试手段就是printk配合dmesg。printk的日志级别决定了消息输出到控制台还是只存环形缓冲区。默认的KERN_INFO级别在很多系统上不会直接显示到控制台，需要通过dmesg查看。

printk在正式驱动代码里别当printf用，刷屏式的日志会让你的系统比正常慢几个数量级。内核社区推荐用dev_info/dev_dbg/dev_err这些封装好的接口，它们会带上设备和driver信息，日志可读性高不少。

动态调试（dynamic_debug）被打开后，dev_dbg可以通过以下命令动态控制输出：

echo 'file demo.c +p' > /sys/kernel/debug/dynamic_debug/control

这个功能可以让你在线上环境开调试，不需要重新编译内核模块，特别适合排查偶发问题。

7.2 oops日志的快速定位方法

insmod后系统oops死机，大家的第一反应是惊慌。其实oops日志里已经给出了核心信息：发生问题的地址、触发异常的指令、寄存器的当前值、以及内核符号表和调用栈。

下面的格式是经典的oops日志：

Unable to handle kernel NULL pointer dereference at virtual address 0x00000000 pgd = 80004000 Oops: 0005 [#1] PREEMPT SMP ARM PC is at demo_read+0x14/0x2c [demo] LR is at vfs_read+0x20/0x110

PC一行告诉你在demo_read函数偏移0x14处出错。配合addr2line工具反解：

addr2line -e vmlinux -f -C 0x14

如果模块是动态加载的，地址信息可能是相对于模块基址的。拿lk和cat /proc/modules查看模块加载基地址，换算成实际地址再做addr2line。或者更简单的方式是编译时打开CONFIG_DEBUG_INFO，直接把.o文件路径和行号记录进oops信息，省去手动换算。

7.3 insmod失败的常见原因速查

insmod失败是内核驱动开发的日常。常见的fail原因汇总成一张表：

下面这个场景大家一定遇到过：自己在5.10内核上编译好的模块，拿回家插到5.4的开发板上，insmod直接报Invalid module format。具体原因是内核版本号（vermagic）不匹配，驱动模块头部的UTS_RELEASE信息和当前内核不一致。解决方法是不要拷贝编译产物，而是每换一台板子就在那台板子的内核源码树里重新编译一次模块。

如果一定要用同一个模块跑多个内核版本，可以用modprobe --force-vermagic之类的强制手段，但这会导致模块和内核之间ABI不兼容的风险，生产环境不建议使用。真正该做的是给每个内核版本单独维护编译脚本，在CI里自动完成。

7.4 锁定性能瓶颈的排查思路

驱动性能差，第一件事不是上来就调代码，而是先分清楚瓶颈到底在哪一层。用户态代码调用频繁但每次调用都做了太多事，还是驱动层面因为锁竞争导致严重延迟？

一个实用的思路是用ftrace追踪中断延迟和调度事件：

cd /sys/kernel/debug/tracing echo 0 > tracing_on echo 'irq:*' > set_event echo 1 > tracing_on cat trace

ftrace能看到每次中断的进入/退出时间，从而定位中断顶半部是否占用过长时间。另一个工具是perf，它能统计内核函数级的CPU开销和锁等待。之前某个数据采集项目性能不达标，通过perf top发现驱动里的kmalloc占了12%的CPU——后来改成在probe阶段就预分配缓冲区，问题直接解决。

性能优化里有个核心原则：不要相信直觉，相信数据。每次改动前后都用工具量化对比，而不是靠感觉判断快慢。我自己就犯过瞎优化一堆代码，结果关键瓶颈在设备树里配置的一个不合量的延时参数这种低级错误，数据一测就现原形了。

8. 最后的经验分享：构建稳定驱动的五个习惯

驱动开发想少踩坑，除了技术细节，日常工作的习惯也很重要。

第一，代码提交前自己做一轮code review。内核驱动的错误往往是逻辑错误，编译器检查不出来的。我通常关注锁是否都配对、错误码是否都返回负数、copy_to_user/copy_from_user的返回值有没有全部处理、资源申请失败时probe路径有没有完整回滚。

第二，给自己的驱动写一个完整的test case。不只是应用层的功能测试，还要模拟设备异常、内存压力、高频并发访问这些场景。一个驱动要真正确认稳定，至少要通过几百轮并发读写压力测试。

第三，把驱动里所有硬件相关的寄存器操作封装成独立的函数，不要散落在各处。这样如果硬件勘误或者平台差异需要适配，只需要修改对应函数即可。我之前维护过的一个老驱动，寄存器操作散在各处，后来芯片改版需要统一增加软件延时，改得极其痛苦。

第四，注意所有sleep、msleep、usleep_range的使用位置，确认不在原子上下文里调用。内核有专门的CONFIG_DEBUG_ATOMIC_SLEEP检测选项，打开后能自动发现这种错误。

第五，也是最重要的一点：接受“内核驱动开发没有银弹”这个事实。每一个看起来奇怪的bug，背后几乎都有确切的内核机制原因。耐心点，一步步查，总能找到真相。我自己最崩溃的那次排查，是在一个生产板子上偶发死机，查了两周都没结果，最后发现是一个共享指针在多核环境下的并发访问没有保护，导致偶尔的野指针。从那以后，我对“所有成员都要考虑并发”这句话的理解深刻了很多。

希望这些经验能让你的驱动开发路走得顺利一些。内核驱动这个领域，最终拼的是细心和耐心，技术本身反而不是最大的门槛。