企业官网建设流程全解析

嵌入式驱动开发这个方向，外面看着门槛高，进去之后发现真正难的不是写代码，而是搞清楚"为什么这么写"。我做了十多年驱动，从裸机寄存器到Linux内核子系统都趟过一遍，带过不少新人，发现大家卡住的地方高度相似：不是C语言不行，也不是看不懂芯片手册，而是脑子里没有建立起"驱动到底在解决什么问题"的框架。这篇文章我把自己这些年积累的经验、踩过的坑、带人时反复讲的那些道理整理出来，不管你是刚入行的嵌入式软件工程师，还是从应用层想往底层转的老手，都能从中找到对自己有用的东西。

1. 驱动开发的本质：在硬件和应用之间做翻译

1.1 驱动到底在翻译什么

很多人对驱动的理解停留在"操作寄存器"这个层面，觉得驱动开发就是查手册、填寄存器、把数据读写跑通。这个理解不算错，但太浅了。驱动的核心职责是把硬件的行为抽象成软件可以理解的接口，让上层应用不需要知道底下接的是什么芯片、走的是什么总线、时序要求是多少纳秒。

打个比方，你家里墙上有个开关，按一下灯就亮。你不需要知道这个开关背后是继电器还是可控硅，不需要知道电线走的是火线还是零线，更不需要知道发电厂用的是什么锅炉。开关就是驱动提供给应用的接口，灯亮就是驱动完成的功能。驱动的价值在于屏蔽复杂性，而不是简单地"操作硬件"。

这个认知非常重要，因为它直接决定了你写驱动的思路。如果你只想着"我要把数据写到这个寄存器"，那你写出来的驱动就是一堆散乱的寄存器操作，换个芯片就得重写。但如果你想着"我要给上层提供一个稳定的、与硬件无关的接口"，那你就会自然地去做分层、做抽象、做错误处理。

1.2 驱动工程师的三层能力模型

我带新人的时候，习惯把驱动工程师的能力分成三层：

第一层是能跑通。拿到一块板子，能根据芯片手册把GPIO、UART、I2C这些基础外设的驱动写出来，数据能收能发，功能正常。这一层靠的是对寄存器操作和总线协议的理解，是基本功，但也是最容易被替代的一层。

第二层是能扛住。驱动在实验室跑通不难，难的是在现场跑三个月不出问题。这要求你考虑中断风暴怎么处理、DMA缓冲区怎么管理、并发访问怎么加锁、电源管理怎么配合、异常恢复怎么做。这一层靠的是对操作系统机制的理解和对边界条件的敏感度。

第三层是能设计。面对一个复杂的硬件模块，你能设计出一套清晰的驱动架构，把硬件差异封装在底层，给上层提供统一的接口，同时预留扩展点。这一层靠的是抽象能力和对业务场景的理解。

大部分卡在第一层到第二层之间，能写功能但扛不住异常。这篇文章后面会重点讲第二层和第三层的东西，因为这才是区分普通驱动工程师和资深驱动工程师的分水岭。

1.3 从"能跑"到"能扛"的关键跨越

我见过太多驱动代码，功能测试全过，一上量产就出问题。举几个真实的例子：

有个项目做按键驱动，实验室里按几百次都没事，到了现场用户快速连按就丢键。原因是驱动里用了阻塞式扫描，每次按键处理要等消抖延时，延时期间的新按键直接被忽略了。这就是典型的"能跑但不能扛"。

还有个项目做串口驱动，测试时收发正常，现场跑了两天突然死机。查了半天发现是中断处理函数里做了太多事情，某个异常情况下中断嵌套太深导致栈溢出。这也是"能跑但不能扛"。

从"能跑"到"能扛"的跨越，核心在于思维方式要从"正常流程"转向"异常流程"。写代码的时候不能只想"一切正常会怎样"，而要想"如果这里出错会怎样""如果两个中断同时来会怎样""如果这个操作超时了会怎样"。这种思维习惯需要刻意练习，但一旦建立起来，你写的驱动质量会有质的飞跃。

2. 嵌入式Linux驱动开发的环境搭建与第一个可加载模块

2.1 交叉编译工具链的选择与验证

做嵌入式Linux驱动，第一步是搭环境。这里面最容易出问题的不是工具链安装本身，而是工具链和内核版本的匹配。

我推荐的做法是：先确定目标板用的内核版本，然后找芯片原厂或板卡厂商提供的工具链。不要随便从网上下一个通用工具链就用，因为不同工具链的glibc版本、内核头文件版本可能和你编译的内核不匹配，编出来的模块加载时会报"version magic"错误。

验证工具链是否可用，可以写一个最简单的hello world程序交叉编译一下：

arm-linux-gnueabihf-gcc -o hello hello.c file hello

如果输出显示是ARM架构的可执行文件，说明工具链基本可用。但真正要确认的是它能不能编译内核模块，这个后面编译模块时才能验证。

提示：工具链的路径一定要加到环境变量里，或者在Makefile里写绝对路径。我见过有人编译时用的是系统自带的gcc，编出来的模块架构不对，加载时报"invalid module format"，查了半天才发现是PATH的问题。

2.2 内核源码的准备与编译

编译驱动模块需要内核源码，而且必须是和目标板运行的内核完全一致的源码，包括配置。差一个配置选项，编出来的模块就可能加载不了。

获取内核源码后，第一步是配置。如果目标板厂商提供了配置文件（通常是arch/arm/configs/下的某个defconfig），直接用那个配置最稳妥：

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- xxx_defconfig make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- modules_prepare

注意这里用的是modules_prepare而不是完整的make。如果你只是编译模块，不需要编译整个内核，modules_prepare会准备好编译模块所需的环境，速度快很多。

但有个坑：modules_prepare不会生成Module.symvers文件，如果你的模块依赖其他模块导出的符号，编译时会报"undefined symbol"。解决办法是先完整编译一次内核，或者从目标板上把/proc/kallsyms导出来处理。

2.3 第一个可加载模块的编写与加载

环境准备好之后，写一个最简单的模块练手：

#include <linux/module.h> #include <linux/kernel.h> #include <linux/init.h> static int __init hello_init(void) { printk(KERN_INFO "hello module loaded\n"); return 0; } static void __exit hello_exit(void) { printk(KERN_INFO "hello module unloaded\n"); } module_init(hello_init); module_exit(hello_exit); MODULE_LICENSE("GPL"); MODULE_AUTHOR("your name"); MODULE_DESCRIPTION("a simple hello module");

对应的Makefile：

obj-m += hello.o KDIR := /path/to/kernel/source PWD := $(shell pwd) all: $(MAKE) -C $(KDIR) M=$(PWD) modules clean: $(MAKE) -C $(KDIR) M=$(PWD) clean

编译出hello.ko之后，通过NFS或者U盘拷到目标板，用insmod hello.ko加载，dmesg看输出。

注意：MODULE_LICENSE("GPL")这行不能省。不写的话内核会认为你是私有模块，很多内核导出的符号你用不了，而且会在内核日志里留下"tainted"标记。我见过有人调试半天发现某个函数调不了，就是因为license没写对。

2.4 模块加载失败的常见原因排查

模块加载失败是最常见的问题，报错信息往往很简短，需要你自己去定位。我整理了一个排查顺序：

vermagic这个字段特别重要，它包含了内核版本、SMP配置、抢占配置等信息。只要有一项不匹配，模块就加载不了。所以编译模块的内核源码必须和目标板运行的内核完全一致，这不是建议，是硬性要求。

3. 字符设备驱动的核心骨架与文件操作接口

3.1 设备号的分配与管理

字符设备驱动是Linux驱动里最基础也最常用的一类。它的核心是向内核注册一个设备号，并实现一组文件操作接口，让用户空间可以通过/dev/xxx来访问硬件。

设备号分主设备号和次设备号。主设备号标识驱动，次设备号标识同一驱动下的不同设备。分配设备号有两种方式：

静态分配用register_chrdev_region，你需要自己指定一个主设备号。这种方式的问题是容易和系统里已有的设备号冲突，而且换个环境可能就不一样了。

动态分配用alloc_chrdev_region，内核帮你找一个空闲的主设备号。这是推荐的方式，但缺点是每次加载主设备号可能不同，需要配合udev或者mknod来创建设备节点。

static dev_t dev_num; static int major; static int __init mydev_init(void) { int ret; ret = alloc_chrdev_region(&dev_num, 0, 1, "mydev"); if (ret < 0) { printk(KERN_ERR "alloc chrdev failed\n"); return ret; } major = MAJOR(dev_num); printk(KERN_INFO "major = %d\n", major); return 0; }

3.2 file_operations结构体的实现要点

file_operations是字符设备驱动的灵魂，它定义了用户空间能对这个设备做哪些操作。最常用的几个成员是open、release、read、write、ioctl。

static int mydev_open(struct inode *inode, struct file *filp) { printk(KERN_INFO "mydev opened\n"); return 0; } static ssize_t mydev_read(struct file *filp, char __user *buf, size_t count, loff_t *f_pos) { char kbuf[64] = "hello from kernel"; if (copy_to_user(buf, kbuf, strlen(kbuf))) return -EFAULT; return strlen(kbuf); } static struct file_operations mydev_fops = { .owner = THIS_MODULE, .open = mydev_open, .release = mydev_release, .read = mydev_read, .write = mydev_write, .unlocked_ioctl = mydev_ioctl, };

这里有几个关键点：

copy_to_user和copy_from_user不能省。内核空间和用户空间的地址不能直接互相访问，必须通过这两个函数拷贝。直接解引用用户空间指针在大多数架构上会出问题，即使侥幸能跑也是不安全的。

__user这个标记要加上。它告诉编译器这个指针指向用户空间，帮助做静态检查。虽然不加也能编译，但加了之后如果误用编译器会警告。

返回值要符合约定。read返回实际读取的字节数，write返回实际写入的字节数，出错返回负的错误码。返回0在read里表示EOF，在write里表示什么都没写。

3.3 用户空间与内核空间的数据交互

数据交互是字符设备驱动里最容易出问题的地方。除了copy_to_user和copy_from_user，还有几个细节需要注意：

用户指针可能无效。用户传进来的指针可能指向未映射的内存，copy_to_user会返回非零值，你必须检查并返回-EFAULT。不检查的话，用户程序传个野指针进来，你的驱动就崩了。

数据长度要校验。用户可能传一个巨大的count进来，你不能直接按这个长度分配内核缓冲区，否则可能耗尽内存。正确的做法是限制单次传输的最大长度，或者用分块传输。

并发访问要保护。如果多个进程同时打开同一个设备并读写，共享的数据结构需要加锁。最简单的用互斥锁：

static DEFINE_MUTEX(mydev_mutex); static ssize_t mydev_write(struct file *filp, const char __user *buf, size_t count, loff_t *f_pos) { mutex_lock(&mydev_mutex); /* 临界区操作 */ mutex_unlock(&mydev_mutex); return count; }

提示：锁的粒度要合适。锁太大影响并发性能，锁太小保护不住共享数据。一个原则是：锁保护的是数据，不是代码。想清楚哪些数据是共享的，在访问这些数据的地方加锁。

3.4 设备节点的自动创建：class与udev的配合

手动mknod创建设备节点太麻烦，而且主设备号动态分配时每次都要改。正确做法是用class_create和device_create让内核自动创建：

static struct class *mydev_class; static struct device *mydev_device; mydev_class = class_create(THIS_MODULE, "mydev"); if (IS_ERR(mydev_class)) { unregister_chrdev_region(dev_num, 1); return PTR_ERR(mydev_class); } mydev_device = device_create(mydev_class, NULL, dev_num, NULL, "mydev%d", 0); if (IS_ERR(mydev_device)) { class_destroy(mydev_class); unregister_chrdev_region(dev_num, 1); return PTR_ERR(mydev_device); }

这样加载模块后，/dev/mydev0会自动出现。卸载时按相反顺序清理：

device_destroy(mydev_class, dev_num); class_destroy(mydev_class); unregister_chrdev_region(dev_num, 1);

清理顺序不能乱，否则会留下悬空指针或者资源泄漏。我见过有人卸载模块时先unregister_chrdev_region再device_destroy，结果内核报了一堆错误。资源申请和释放的顺序必须严格相反，这是驱动开发的基本纪律。

4. 中断处理与并发控制：驱动稳定性的分水岭

4.1 中断上下文的限制与正确使用

中断处理是驱动开发里最容易出问题的地方，因为中断上下文和进程上下文有本质区别。在中断处理函数里，你不能睡眠，不能调用可能睡眠的函数，不能访问用户空间。

为什么不能睡眠？因为中断处理函数运行在中断上下文，没有进程上下文可以调度。如果你在中断处理函数里睡眠了，内核无法切换到其他进程，整个系统就卡住了。

那哪些操作会睡眠？kmalloc带GFP_KERNEL标志会睡眠，mutex_lock会睡眠，copy_to_user会睡眠，msleep会睡眠。这些在中断处理函数里都不能用。

正确的做法是中断处理函数只做最紧急的事情，把耗时的处理放到下半部。Linux提供了几种下半部机制：

对于大多数驱动，workqueue或者threaded irq是最省心的选择，因为它们运行在进程上下文，可以睡眠，可以用互斥锁，可以调用大部分内核API。

4.2 自旋锁与互斥锁的选择依据

并发控制是驱动稳定性的核心。Linux提供了多种锁机制，选错了不仅影响性能，还可能导致死锁。

自旋锁（spinlock）的特点是忙等待，不睡眠。它适合保护很短的临界区，而且可以在中断上下文使用。但自旋锁期间不能睡眠，也不能做耗时操作，否则会浪费CPU。

互斥锁（mutex）的特点是睡眠等待，适合保护较长的临界区。它只能在进程上下文使用，不能在中断上下文使用。

选择依据很简单：

• 如果临界区在中断上下文访问，只能用自旋锁
• 如果临界区可能睡眠，只能用互斥锁
• 如果临界区很短（几条指令），用自旋锁
• 如果临界区较长（可能几百个指令），用互斥锁

还有一个容易忽略的点：自旋锁在单核和多核上的行为不同。单核上自旋锁只是关中断，多核上才是真正的忙等待。所以单核上测试没问题的代码，多核上可能出问题。测试的时候要尽量在多核环境验证。

4.3 中断下半部的三种实现方式对比

前面提到了softirq、tasklet、workqueue三种下半部机制，这里展开说一下它们的区别和选择。

softirq是性能最高的，但也是最难用的。它需要静态注册，同一类型的softirq可以在多个CPU上并行执行，所以处理函数必须是可重入的。一般驱动开发者不需要直接用softirq，内核的网络和块设备子系统已经用得很好了。

tasklet是基于softirq实现的，但同一类型的tasklet不会并行执行，用起来简单很多。它的处理函数运行在中断上下文，不能睡眠。适合那些不需要睡眠的延迟处理。

workqueue把工作推送到内核线程执行，运行在进程上下文，可以睡眠。这是最灵活的机制，适合大多数场景。缺点是上下文切换有开销，延迟比tasklet大。

我的经验是：除非有明确的性能要求，否则优先用workqueue。它最不容易出错，调试也最方便。tasklet虽然快，但一旦在tasklet里不小心调用了可能睡眠的函数，问题很难排查。

4.4 并发场景下的数据一致性保障

并发问题往往不是功能测试能发现的，而是在压力测试或者现场运行一段时间后才暴露。我总结了几种常见的并发场景和应对方法：

场景一：多个进程同时读写设备。用互斥锁保护共享数据，注意锁的粒度。

场景二：中断处理函数和进程上下文访问同一数据。用自旋锁加关中断：

unsigned long flags; spin_lock_irqsave(&my_lock, flags); /* 临界区 */ spin_unlock_irqrestore(&my_lock, flags);

场景三：多个CPU同时访问同一数据。除了加锁，还要考虑内存屏障。有些架构的CPU会乱序执行，不加屏障可能导致数据可见性问题。不过对于大多数驱动，用锁就够了，锁本身包含了内存屏障语义。

场景四：设备热插拔时的竞态。设备被拔掉的同时用户还在读写，这时候驱动必须能正确处理。通常的做法是在disconnect里把设备标记为不可用，然后等待正在进行的操作完成。

注意：并发问题最难的地方不是加锁本身，而是想清楚哪些数据是共享的。我建议在写驱动之前先画一张数据流图，标出哪些数据会被多个上下文访问，然后针对性地加锁。这比事后补锁要可靠得多。

5. 平台设备驱动模型与设备树的配合

5.1 平台设备驱动模型解决了什么问题

早期的Linux驱动把硬件信息硬编码在代码里，换个板子就要改驱动。这显然不合理，因为同一个SoC可以用在不同板子上，同一个驱动应该能适配不同的硬件配置。

平台设备驱动模型（platform device driver）就是为了解决这个问题。它把驱动分成两部分：设备（device）描述硬件资源，驱动（driver）描述操作方法。两者通过名字匹配，匹配成功后驱动就能拿到设备描述的资源。

在设备树（Device Tree）出现之前，设备信息通常写在板级文件里。有了设备树之后，硬件信息从内核代码里剥离出来，放在独立的.dts文件里，驱动只需要通过标准API读取设备树节点就能拿到资源。

5.2 设备树节点的编写与解析

设备树是嵌入式Linux驱动开发必须掌握的技能。一个典型的设备树节点长这样：

mydev: mydev@10000000 { compatible = "vendor,mydev"; reg = <0x10000000 0x1000>; interrupts = <0 32 4>; clocks = <&clk_gate 5>; clock-names = "mydev_clk"; status = "okay"; };

驱动里通过compatible属性匹配设备：

static const struct of_device_id mydev_of_match[] = { { .compatible = "vendor,mydev" }, { } }; MODULE_DEVICE_TABLE(of, mydev_of_match); static struct platform_driver mydev_driver = { .probe = mydev_probe, .remove = mydev_remove, .driver = { .name = "mydev", .of_match_table = mydev_of_match, }, }; module_platform_driver(mydev_driver);

在probe函数里解析设备树：

static int mydev_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); if (irq < 0) return irq; /* 初始化硬件 */ return 0; }

5.3 probe函数的执行时机与资源申请

probe函数是平台驱动的核心，它在设备和驱动匹配成功后调用。这里有几个关键点：

probe可能被延迟。如果驱动依赖的时钟、电源、GPIO等资源还没准备好，probe会返回-EPROBE_DEFER，内核会稍后重试。这是正常的，不要把它当成错误。

资源申请要用devm系列函数。devm_ioremap_resource、devm_kzalloc、devm_request_irq这些函数申请的资源会在设备卸载时自动释放，不需要你手动清理。这能避免很多资源泄漏问题。

probe里要做完整的错误处理。任何一步失败都要回滚已经做的操作。用devm系列函数能简化很多，但有些资源还是需要手动管理。

提示：probe函数里不要做太耗时的操作，否则会影响系统启动速度。如果确实需要耗时初始化，可以放到workqueue里异步执行。但要注意，异步初始化完成之前，设备不能对外提供服务。

5.4 设备树与驱动匹配失败的排查思路

设备树和驱动匹配失败是新手最常遇到的问题。现象是驱动加载了，但probe函数没被调用。排查思路如下：

第一步，确认设备树节点是否存在。在目标板上执行：

ls /proc/device-tree/

看看你的节点在不在。如果不在，说明设备树没编译进去或者被覆盖了。

第二步，确认compatible属性是否匹配。对比设备树里的compatible和驱动里的of_device_id，必须完全一致，包括厂商前缀。

第三步，确认status属性。设备树节点的status必须是"okay"或者不写（默认okay）。如果是"disabled"，驱动不会匹配。

第四步，看内核日志。dmesg里通常会有匹配相关的信息，比如"not found"或者"probe deferred"。

第五步，确认驱动是否注册成功。在/sys/bus/platform/drivers/下看你的驱动目录是否存在，里面有没有绑定设备。

这套排查流程我用了很多次，基本上能覆盖90%的匹配问题。

6. 驱动调试手段与常见问题定位

6.1 printk的等级控制与动态调试

printk是最常用的调试手段，但用不好会刷屏。关键是合理使用日志等级：

printk(KERN_ERR "this is an error\n"); /* 等级3 */ printk(KERN_WARNING "this is a warning\n"); /* 等级4 */ printk(KERN_INFO "this is info\n"); /* 等级6 */ printk(KERN_DEBUG "this is debug\n"); /* 等级7 */

控制台默认只显示等级高于某个值的日志。可以通过/proc/sys/kernel/printk查看和修改：

cat /proc/sys/kernel/printk # 输出：7 4 1 7 # 第一个是控制台等级，第二个是默认等级

调试阶段可以把控制台等级调低，看到更多日志：

echo 8 > /proc/sys/kernel/printk

但发布版本一定要把调试日志去掉或者降级，否则会影响性能，还可能泄露敏感信息。

更高级的调试手段是动态调试（dynamic debug），它允许你在运行时开关某条日志，不需要重新编译：

pr_debug("this is a debug message\n"); dev_dbg(&pdev->dev, "device debug message\n");

开启方法：

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

6.2 ftrace跟踪驱动执行流程

ftrace是内核自带的跟踪工具，能跟踪函数调用、中断、调度等事件。对于驱动调试，最常用的是function_graph跟踪器：

cd /sys/kernel/debug/tracing echo function_graph > current_tracer echo mydev_probe > set_graph_function echo 1 > tracing_on # 触发probe echo 0 > tracing_on cat trace

这样能看到probe函数里每个子函数的调用和耗时，快速定位性能瓶颈。

6.3 常见oops信息的解读方法

驱动出问题最怕的就是内核oops。oops信息看起来吓人，但读懂之后定位问题并不难。关键看几个部分：

PC指针告诉你出问题的指令地址，用addr2line或者gdb能定位到源码行。

Call trace告诉你函数调用链，从下往上看，能找到出问题的函数。

寄存器值能看出当时的上下文，比如访问了什么地址。

一个典型的oops：

Unable to handle kernel NULL pointer dereference at virtual address 00000000 PC is at mydev_read+0x1c/0x40

这说明mydev_read函数里解引用了空指针。结合源码看，通常是忘了检查某个指针是否为空。

注意：oops信息里的地址是虚拟地址，需要结合内核的地址映射来理解。如果开了KASLR（内核地址随机化），每次启动的地址都不一样，需要用/proc/kallsyms来对照。

6.4 内存泄漏与竞态问题的排查工具

内存泄漏在驱动里很常见，尤其是手动管理内存的时候。排查工具有几个：

kmemleak是内核自带的内存泄漏检测工具，开启后能报告未释放的内存块：

echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak

slub_debug能检测内存越界和重复释放：

# 内核启动参数加 slub_debug=FZPU

竞态问题用KCSAN（Kernel Concurrency Sanitizer）检测，它能发现数据竞争：

# 内核配置开启 CONFIG_KCSAN

这些工具都有性能开销，只在调试阶段开启。

7. 从驱动开发到系统级问题的排查思路

7.1 驱动问题与应用问题的边界划分

现场出问题，怎么判断是驱动的问题还是应用的问题？我的经验是看问题的表现特征：

驱动问题的典型特征：系统崩溃、oops、设备无响应、数据错误但应用逻辑正常、问题在特定硬件操作时出现。

应用问题的典型特征：功能不符合预期但系统稳定、日志显示应用层错误、问题在特定业务逻辑时出现。

但有些问题处于边界地带，比如应用读写设备超时。这时候需要看驱动有没有正确返回错误码，应用有没有正确处理错误。我通常的做法是在驱动里加详细的日志，记录每次操作的入口、出口、返回值，然后对比应用的行为。

7.2 系统卡死时的现场信息采集

系统卡死是最难排查的问题，因为这时候你没法登录系统看日志。有几个手段可以采集现场信息：

Magic SysRq是内核提供的紧急操作接口，通过串口发送特定组合键能触发。常用的有：

• SysRq-t：打印所有任务的状态
• SysRq-m：打印内存信息
• SysRq-w：打印阻塞的任务
• SysRq-c：触发崩溃转储

kdump能在系统崩溃时把内存转储到磁盘，重启后分析。配置稍复杂，但对于排查偶发崩溃很有价值。

看门狗能在系统卡死时自动重启，配合日志能缩小问题范围。

7.3 性能瓶颈的定位：从驱动层到应用层

性能问题往往涉及多个层次，定位思路是自底向上：

先看驱动层有没有明显的性能问题，比如中断处理太慢、DMA没用好、锁竞争严重。用ftrace和perf能看出来。

再看内核层有没有瓶颈，比如调度延迟、内存回收频繁。用perf top和vmstat能看出来。

最后看应用层有没有问题，比如系统调用太频繁、缓冲区太小。用strace能看出来。

我遇到过一个案例：应用读写设备很慢，查了半天发现是驱动里每次读写都重新映射了寄存器，映射操作很耗时。改成初始化时映射一次，性能提升了十几倍。这种问题不看驱动代码是发现不了的。

7.4 驱动代码review的检查清单

最后分享一份我用了多年的驱动代码review清单，每次review驱动代码都过一遍：

这份清单看起来简单，但真正每条都做到位的驱动不多。我见过太多驱动功能正常但一上压力就出问题，根源都是这些基础项没做好。

驱动开发这个方向，入门容易精通难。功能跑通只是起点，真正的功夫在异常处理、并发控制、性能优化这些地方。我个人的体会是，写驱动要有一颗敬畏心，因为你写的代码运行在内核态，一个错误就可能导致整个系统崩溃。每次提交代码前多问自己几个"如果"，很多问题就能提前发现。另外，多读内核源码里成熟的驱动，看看别人是怎么处理类似问题的，这比看任何教程都管用。