企业官网建设流程全解析

距离 27 届秋招还有一段时间，但嵌入式驱动岗的面试准备，其实已经不算早了。这两年嵌入式方向的竞争明显比前几年更卷，尤其是 Linux 驱动岗，几乎到了“人手一个项目”的程度。面试官早就不是靠问“你做过什么”来筛人了，而是换成了更直接的方式：从一个问题出发，一路追到底，直到你答不上来为止。这就是大家常说的“面试十连问”。

这里说的“十连问”，不是十个孤立的问题，而是十条追问链。每一条都从一个大问题开始，比如“字符设备驱动怎么写”，然后顺着你的回答往下挖：设备号怎么分配？register_chrdev 和 cdev_add 有什么区别？file_operations 里的 read 是怎么被调用的？为什么不能直接用 memcpy 传数据？越问越细，越问越靠近内核源码，也越问越靠近你到底有没有亲手写过驱动。

这篇文章就把驱动岗面试里最常见的十条追问链拆开讲一遍。每条链我都会说明：面试官想考察什么、核心知识点是什么、回答时要注意什么，以及最容易翻车的点在哪里。如果你还在准备阶段，可以把这篇文章当成一张检查清单，一条一条对照自己掌握到什么程度。

1. 第一条问链：insmod 之后到底发生了什么

很多同学准备驱动面试，第一反应是背 insmod、rmmod、module_init、module_exit 这几个宏。这没错，但面试官一般不会从这里开始问。更常见的开场是：

“你写过一个字符设备驱动吧？那 insmod 一个 .ko 文件之后，内核到底做了哪些事？”

这个问题看起来基础，实际上能分出三个层次。

第一层，能答出来模块加载会调用 module_init 注册的函数，模块卸载会调用 module_exit。这是底线。

第二层，要能说出模块可能被编译进内核，也可能被编译成模块，两者加载时机不同，初始化调用方式也不同。运行时加载走的路径最终会执行模块的 init 函数。

第三层，面试官会追问：同一个模块加载两次会怎样？init 函数返回错误后，模块会不会继续留在内核里？卸载时设备还在被占用，rmmod 会失败吗？这些答案都指向引用计数、模块状态和资源释放顺序。

这一条链考的不是你会不会用 insmod，而是你有没有真正理解模块的完整生命周期。建议回答时按“模块加载到内核 → 内核分配模块对象 → 调用 init 函数 → init 里完成设备注册和资源申请 → 失败时回滚已占用资源 → 卸载时清理资源并释放模块”这条线展开，面试官会觉得你脑子里有一张完整图景，而不是只记住了几个宏。

1.1 设备号的问题最容易被追问

字符设备驱动的核心是设备号。面试官在这个地方通常会连续问三四个问题：

• 主设备号和次设备号分别代表什么？
• register_chrdev 和 cdev_add 有什么区别？
• 申请设备号有哪几种方式？
• 为什么现在建议用动态分配而不是静态指定？

如果你只背了“register_chrdev 是老接口，cdev_add 是新的”这种结论，大概率过不了。更好的答法是讲清楚：register_chrdev 在注册时会同时申请设备号、创建 cdev 并注册到内核，整个流程比较粗放；而 cdev_add 只是把已经初始化好的 cdev 对象加入内核，设备号需要先用 alloc_chrdev_region 或 register_chrdev_region 分配。后者适合现代驱动写法，因为你可以更精确地控制 cdev 的生命周期，也方便一个驱动管理多个设备号。

动态分配和静态指定的区别也要会讲。静态指定是“我就要用这个设备号”，如果系统里已经有别的驱动占用，加载就会失败。动态分配是“内核你随便给我一个”，通过 cat /proc/devices 可以看到分配结果。实际产品里硬编码设备号的情况越来越少，面试官默认你懂动态分配。

1.2 file_operations 是这一链的收尾问题

字符设备驱动绕不开 file_operations。十连问到这里，一般会问：一个字符设备注册好之后，用户在应用层 open("/dev/xxx")，内核是怎么找到你的 open 函数的？

这里要能说出 VFS 到设备驱动的调用链路：应用层 open → 系统调用 → VFS 根据 inode 找到 cdev → cdev 关联的 file_operations 被填充到 struct file → 调用对应的 open 方法。

另外还有一个高频追问：.owner 字段为什么要设置成 THIS_MODULE？答案是为了管理模块引用计数。如果设备正被使用，模块卸载操作会因为引用计数不为零而被拒绝。一个细节能挡住不少只背代码不思考的候选人。

2. 第二条问链：platform 总线、设备树和 probe

第二条高频追问链从“驱动和设备怎么匹配”开始。

“你写驱动的时候，probe 函数什么时候会被调用？”

如果答不上来，或者只回答“设备匹配之后”，面试官会接着追问：“怎么匹配？谁和谁匹配？”

这是嵌入式 Linux 驱动面试的分水岭。能讲清楚这个问题的，说明真的写过基于设备树或者传统 platform 设备的驱动；讲不清楚的，基本就是在八股文里背过 cdev 注册流程。

2.1 匹配机制要按三种情况分开讲

平台驱动和设备有三种匹配方式。

第一种是基于设备树。设备树节点里的 compatible 字符串和驱动里 of_match_table 中的 compatible 一致，就会触发匹配。这是现在 ARM 平台最常用的方式。

第二种是基于 platform_device 和 platform_driver 的 id_table。驱动里定义 platform_device_id 数组，把 name 字段和设备的 name 对齐，也能匹配。

第三种是和设备树解耦的老方式，通过 device_register 和 driver_register 直接注册，匹配逻辑走总线自己的 match 函数。

回答时要把三者的适用场景讲清楚：新项目基本都用设备树，老的 ARM 平台还有 id_table 方式，x86 和某些模拟环境下可能直接注册平台设备。如果能补一句“匹配成功之后，总线核心会调用 driver 的 probe 方法，probe 里再做资源获取和设备初始化”，这条链就完整了。

2.2 设备树节点要会看也要会写

驱动岗面试基本必考设备树。常见问题是：“如果芯片外接了一个 I2C 触摸屏，设备树里应该怎么加节点？”

这个问题考察的是：

• 知道 I2C 节点挂在哪个总线上
• 知道 compatible、reg、interrupts、pinctrl 分别是什么作用
• 知道驱动的 of_match_table 和节点 compatible 怎么对应
• 知道 reg 里的地址是 I2C 从机地址还是寄存器地址

很多同学能背出设备树长什么样，但实际写不出来。面试的时候如果让手写一个简单外设节点，能一字不错写出来的人是少数。建议把设备树骨架、compatible 命名规则、reg 属性含义整理成模板，做到随时能默写，而不是到现场再现场拼凑。

3. 第三条问链：read/write/ioctl 与数据拷贝

file_operations 里的 read、write、ioctl 是驱动面试的必考区。不过面试官不会只问“函数原型是什么”，而是会问：

“应用层调用 read(fd, buf, len) 之后，驱动里的 read 函数是直接往 buf 里写数据吗？”

答案当然不是。内核态不能直接访问用户态指针。驱动里要用 copy_to_user 和 copy_from_user 来完成数据拷贝。接下来就会问：

• 为什么不能用 memcpy？
• copy_to_user 返回值和你的 read 返回值是一回事吗？
• 如果用户传进来的指针是非法地址，会发生什么？

3.1 copy_to_user 为什么不能省

这个问题严格来说要分场景。如果访问的是合法的用户空间缓冲区，memcpy 在大多数架构上也能工作，但这属于“碰巧能用”，不是“应该用”。copy_to_user 会做地址范围检查，确认指针是否属于用户可访问区域，同时因为目标是用户内存，还要处理缺页问题。在用户内存可能被换出、被映射到文件页、或者地址非法的情况下，copy_to_user 才更安全。

回答时如果能补一句“如果传入的指针指向内核地址，copy_to_user 大概率会拒绝拷贝”，会显得你对地址空间和安全有意识。

3.2 返回值是整个面试最容易出错的地方

驱动里的 read 函数返回值，考察的是你对系统调用约定的理解。

• 返回正数：成功读取的字节数
• 返回 0：表示 EOF
• 返回负数：错误码，比如 -EINVAL、-ENOMEM

很多同学把这个和 copy_to_user 的返回值混在一起。copy_to_user 返回的是“没能拷贝成功的字节数”，成功时为 0。所以常见写法是 if (copy_to_user(...)) return -EFAULT;。这个细节面试官会故意追问，答错了会留下很坏的印象。

3.3 ioctl 为什么越写越乱

ioctl 的考察点一般是命令编码。Linux 内核用 _IO、_IOR、_IOW、_IOWR 宏来生成命令号，里面编码了方向、大小和魔数。面试官想听到的是：基于 size 的校验可以让内核判断命令是否合法，避免用户传一个过大的命令导致越界访问。

ioctl 的坏味道是每个驱动都写一个巨大的 switch-case。更合适的做法是尽量用 read/write 替代一部分控制功能，或者把 ioctl 里的每个分支拆成独立处理函数。面试时如果能主动提到这种设计取舍，会比单纯背命令编码公式得分高。

4. 第四条问链：并发与同步，最容易暴露短板

驱动面试的中场，一般会切换到并发与同步。因为这部分最能看出你有没有实际写过多线程或中断环境下的驱动代码。

常见开场是：“你的驱动可能同时被多个进程打开，一个进程在读，另一个进程在写，你怎么保证数据一致？”

4.1 自旋锁和互斥锁必须能讲清使用场景

自旋锁和互斥锁的选择，是驱动岗面试的核心问题之一。面试官想听到的版本不是“自旋锁快，互斥锁慢”，而是：

自旋锁适用于临界区很小、持有时间很短的场景，适合在中断上下文或进程上下文中保护共享资源。它的特点是获取不到锁时原地忙等，所以持锁期间不能睡眠。如果临界区里有可能睡眠的操作，比如 kmalloc(..., GFP_KERNEL)、copy_to_user，就不能用自旋锁。

互斥锁适用于临界区比较大、持有时间较长的场景，获取不到锁时会睡眠，等锁释放后再被唤醒。中断上下文不能用互斥锁，因为睡眠可能触发调度，而中断上下文不能调度。

这里还要注意一个常见追问：自旋锁在单核 CPU 上还有意义吗？答案是仍然有意义。因为自旋锁除了保护多个 CPU 之间的竞争，还要防止中断和进程抢占带来的重入问题。不过也要承认，在单核非抢占内核里，自旋锁的行为会退化成关抢占或关中断。

4.2 原子操作和读写锁不是重点，但要会答

面试官如果继续深挖，会问原子变量、读写锁、RCU。嵌入式驱动岗一般不会要求你把 RCU 讲透，但原子操作几乎必问。原因是驱动开发里经常要做计数、状态标记这类简单操作，用原子变量比加锁更轻量。

“atomic_inc 和 i++ 有什么区别？”这个问题考察的是对竞态的理解。atomic_inc 保证读改写的过程是原子的，在多核环境里不会被其他核打断。回答时顺带提一句“如果只是普通变量，两个 CPU 同时执行 i++ 可能因为读改写非原子而丢更新”，这个印象就会很加分。

5. 第五条问链：中断处理，驱动岗的保留项目

中断是驱动开发里最难绕开的部分。追问链一般从简单的地方切入：

“一个按键按下之后，你的驱动怎么知道这件事发生了？”

回答越具体越好：按键对应 GPIO，GPIO 配置为输入中断模式，设备树里用 interrupts 属性描述中断源，驱动里用 request_irq 或 devm_request_irq 注册中断处理函数。中断触发后，中断处理函数运行在中断上下文，不能做耗时操作，所以通常只做标记，然后调用下半部机制做剩下的工作。

5.1 中断上下文的限制要能列全

面试官接着会问：“为什么中断处理函数里不能做耗时操作？”

标准答案是中断处理函数会阻塞当前中断线，过长的时间会导致中断丢失、系统延迟变大，严重时可能造成实时任务超时。如果使用共享中断线，所有注册了这个中断号的驱动都会受影响。

再深入一点，会问为什么中断上下文不能睡眠。因为中断处理程序运行在中断上下文，不是进程上下文，没有 task_struct 可以调度，睡眠后没有恢复执行的路径。即使能睡，也会让整个系统的调度延迟变得不可控。

这一部分不需要背太多，但要能说清楚“中断上下文不是进程上下文”这个底层逻辑。

5.2 tasklet、workqueue、threaded irq 怎么选

下半部机制是这一问链的落点。面试官会问：

• tasklet 和 workqueue 有什么区别？
• 什么时候用 threaded irq？
• 现在新驱动里为什么越来越多用 threaded irq？

tasklet 运行在软中断上下文，不能睡眠，适合非常小的延迟任务。workqueue 运行在进程上下文，可以睡眠，适合做需要阻塞的任务。threaded irq 把中断处理变成一个内核线程，是很多新驱动推荐的方案。

回答时如果只是背区别，不够加分。更好的做法是结合自己写过的驱动说：比如 tty 驱动里数据量小、要求及时，可能用 tasklet；如果驱动要和 I2C 总线通信，读 EEPROM 或触摸屏数据，那就必须用 workqueue 或 threaded irq，因为 I2C 传输本身可能睡眠。

6. 第六条问链：内核内存和 IO 访问

这一条问链表面上是考察内存分配，实际上是考察你是否知道驱动运行环境和普通用户态程序的区别。

开场一般是：“你在内核里分配内存，用过哪些接口？”

kmalloc、kzalloc、vmalloc 是基础答案。面试官会追一句：“kmalloc 和 vmalloc 有什么区别？”

kmalloc 分配的是物理连续的内存，基于 slab 分配器，适合需要 DMA 或硬件访问的内存。vmalloc 分配的是虚拟地址连续、物理地址不一定连续的内存，适合大数据块。kmalloc 在分配时可能睡眠，具体取决于 flags。

继续追问：GFP_KERNEL 和 GFP_ATOMIC 有什么区别？

GFP_KERNEL 允许分配时睡眠，适合进程上下文。GFP_ATOMIC 不会睡眠，适合中断上下文或持有自旋锁的代码路径。这里要注意，kmalloc(..., GFP_KERNEL) 在使用不当时可能引起睡眠导致死锁，面试官会考察你有没有这个概念。

6.1 IO 内存访问和 ioremap

驱动访问硬件寄存器，几乎都要碰 ioremap。面试官会问：“硬件寄存器的地址能直接通过指针访问吗？”

答案是不能，至少不能不加处理地访问。物理地址必须通过 ioremap 映射到内核虚拟地址空间，然后用 readl/writel 等接口访问。原因包括：有些架构的 IO 空间有特殊语义，需要经过总线桥；编译器不能把 volatile 读写的优化开掉；外设寄存器可能要求特定的访问宽度和顺序。

如果面试官继续追问“/dev/mem 和 mmap 是什么关系”，说明他想知道应用层能不能直接访问物理地址。答案是可以，但需要 root 权限且涉及安全风险。驱动开发和调试时偶尔会用，产品中不建议让业务进程直接操作物理内存。

6.2 内存分配组合要按场景选择

实际项目里，驱动内存分配往往不是单个接口搞定，而是按场景组合。典型问题：

“你要给 DMA 准备一块缓冲区，用 kmalloc 还是 vmalloc？”

DMA 需要物理连续内存，所以优先 kmalloc，或者在启动阶段预留。如果连续内存紧张，可以看看 dma_alloc_coherent，它同时完成一致性映射。这里面试官还想听到一个问题意识：DMA 缓冲区涉及 cache 一致性，驱动里要做同步，不是简单分配完就结束。

回答这类问题时，不需要把每个接口都说得很深，但要把“为什么这么选”讲清楚。能说出接口背后的约束条件，比背住接口名字更有说服力。

7. 第七条问链：阻塞与非阻塞

这一条链经常被安排在对 read 和 write 的深挖中。面试官可能会问：

“如果设备没有数据，我的 read 调用会怎么样？”

7.1 wait queue 是答案的核心

如果驱动采用阻塞式读取，用户进程调用 read 时若没有数据，进程会进入睡眠状态。内部实现是驱动把进程挂到等待队列上，数据来临时用 wake_up 唤醒进程。

要能说出 wait_event_interruptible 和 wake_up 对应的基本用法。如果面试官追问“不可中断睡眠和可中断睡眠有什么区别”，要能答出是否会被信号唤醒。驱动里大多数情况下用 wait_event_interruptible，因为要保证用户进程能被信号打断。

7.2 poll 机制怎么实现

非阻塞 read 会立即返回 -EAGAIN 或者 0，这个容易答。真正有区分度的是 poll 机制：

“应用层用 select/epoll 监听你的设备 fd，驱动里要做什么？”

答案是驱动要实现 file_operations 里的 .poll 方法，调用 poll_wait，把当前 waitqueue 注册到 poll_table，然后返回设备当前可读可写状态的掩码。当设备状态变化时，wake_up 会唤醒 poll_wait 注册的等待项。

这一块很多项目里没写过，面试官问出来就是为了区分有没有真正处理过多个 fd 的事件驱动场景。如果想说“我写过”，至少要能手写一个简单的 .poll 骨架。

8. 第八条问链：内核调试，没写过 bug 就不算真做过

驱动岗面试绕不开调试问题。面试官关心的不是你会不会用 gdb，而是你在内核崩溃之后能不能找到问题。

常见问题包括：

• 你的驱动 panic 了，第一件事做什么？
• 怎么看 oops 信息？
• dmesg 里什么都没有，接下来怎么查？
• 驱动加载之后没报错，但设备不工作，你怎么定位？

8.1 oops 信息读取是基本功

oops 或者 panic 之后，内核会打印寄存器、调用栈、可能出错的符号。要能看懂 RIP/PC 对应的函数，以及调用栈里的函数名。配合 vmlinux 和 addr2line，可以把地址反解成源码行号。如果是模块崩溃，需要先 cat /sys/module/xxx/sections/.text 拿到模块加载基址，再计算偏移。

这个知识点动手写过模块驱动的人一般都会处理，但只刷题的同学往往会卡住。建议提前在自己机器上故意写一个空指针解引用模块，加载后自己分析一次 oops。面试被问到时候，会比别人从容很多。

8.2 日志、节点和探测手段要随手能用

除 oops 之外，面试官还会问：

• printk 的日志级别怎么控制？
• 动态调试怎么开？
• /proc、/sys、/dev 三个目录有什么区别？
• 如果要确认设备树节点有没有匹配成功，去哪里看？

后面这个问题标准答案是 /sys/bus/platform/devices 或者 /sys/firmware/devicetree/base，驱动匹配成功后会在 /sys 下生成设备节点，看 of_node 的符号链接可以确认 compatible 是否匹配。/proc 下主要是内核运行状态，/sys 是设备模型的反映，/dev 是设备文件。三者的定位能讲明白，基本就不会被这类问题难住。

9. 第九条问链：外设子系统，I2C/SPI/UART 只要深讲一个

嵌入式驱动岗面试，一般都会落到一个具体子系统。面试官不会让你把 I2C、SPI、UART 全都讲一遍，但会挑一个你写在简历上的外设，问它的驱动框架。

9.1 I2C 驱动框架至少讲三层

很多同学简历上写“熟悉 I2C 驱动开发”。面试官就顺着问：“一个 I2C 触摸屏驱动，你是怎么组织的？”

I2C 子系统要分成三层来理解：

• controller driver：处理 I2C 控制器的寄存器，负责时序产生。芯片厂商已经写好，一般不需要改。
• core 层：提供 i2c_add_driver、i2c_transfer 等接口，维护总线上的设备与驱动匹配。
• client driver：你的触摸屏驱动在这里。使用 i2c_driver 注册，匹配设备后绑定。

驱动里主要编写的是 i2c_driver 结构、probe 函数，以及用 i2c_transfer 或 smbus 接口和设备通信的代码。probe 里常见操作包括获取 irq、注册输入设备、创建必要的 sysfs 节点。

9.2 追问“读写时序”时别慌

外设驱动的高频追问是：“如果一个 I2C 设备读写到了错误的数据，你怎么排查？”

排查顺序一般是：确认从机地址是否正确 → 确认寄存器地址宽度 → 确认设备是否完成初始化 → 用逻辑分析仪抓 I2C 波形，对比数据手册里的时序要求 → 检查应答位。很多“读不到数据”的问题，最后都是寄存器地址没配对，或者设备还没 ready。

SPI 和 UART 的驱动框架也类似，核心是 controller 与 client 分离。面试时选一个有把握的讲深，比三个都浅尝辄止更有用。

10. 第十条问链：项目经验的“反伪造”深挖

最后这条链不在技术知识本身，而是对你的简历项目进行真实性检验。面试官前面九条链已经基本判断出你的技术水平，最后一轮往往会突然放慢速度：

“你说你做过一个项目，就讲讲你当时怎么开始做驱动的过程吧。”

然后开始连环追问：

• 你遇到了一个什么问题？
• 为什么会出现这个问题？
• 你是怎么定位到原因的？
• 你改了什么代码？
• 怎么验证改对了？
• 现在回头看，有没有更好的方案？

10.1 简历上写的每个技术点都要能讲出细节

驱动岗面试最怕什么？最怕简历上写“精通 Linux 设备模型”，结果问 platform 总线匹配机制答不上来。简历写作的原则是：宁可少写，不要写自己不熟的。

如果写了“熟练使用设备树”，就要能默写一个节点，能解释 chosen、aliases、pinctrl 是干什么的。如果写了“熟悉 DMA”，就要能说出 DMA 映射接口、dma_map_single 和流式映射的一致性要求。

项目部分建议提前准备三个“微故事”：

• 一个硬件问题：比如外设不上电、时钟没配、GPIO 被复用。
• 一个软件问题：比如内存越界、锁使用不当、中断处理过长。
• 一个调试过程：把怎么缩小范围、怎么看日志、怎么验证的步骤写清楚。

每个故事控制在两分钟内能讲完。面试官追问的时候，再往细节里补。

10.2 不会的问题，比硬编更丢分

面试现场遇到不会的问题很正常。驱动岗面试里，面试官更多时候不是在等你背出标准答案，而是在看你的反应路径。

一个比较稳的做法是：先把问题拆成你知道的部分，说出自己的判断，再明确表示这里没深入研究过。比如被问到 RCU，你可以说“RCU 的原理我大概了解，它适合读多写少的场景，通过延迟释放内存来避免读者锁等待，但我在驱动开发里没有实际用过，深入细节还需要看源码确认。”

这种回答比停顿三十秒然后编一个不存在的用法要好得多。面试官要的不是“全知”，而是“知道自己知道什么，也知道自己不知道什么”。

11. 准备方法和优先级

聊完十条链，最后给一个具体的准备顺序。如果你还有时间，按照下面的优先级准备会更高效。

11.1 先把字符设备驱动完整写一遍

不要只看源码，要真的在开发板或虚拟机上把字符设备框架跑起来。建议的路径是：

• 申请设备号
• 初始化 cdev 并添加到内核
• 实现 open/release/read/write
• 用 echo 或 cat 验证数据通路
• 写一个简单的应用层程序做读写测试

这一步做完，第一条链和第三条链的大部分问题都能接住。很多面试问题不是你背熟了就有底气，而是你亲手写过一遍之后，那些代码会变成你的默认思维。

11.2 设备树和 platform 驱动要配合实操

买一块便宜的 ARM 开发板，自己搭一个简单的设备树节点，加载一个 platform 驱动，在 probe 里打印日志，通过 dmesg 观察加载顺序。再尝试把 compatible 改错，观察匹配失败的表现。

这个过程能让你真正理解设备树匹配机制，而不是只在资料里看别人画框架图。条件有限的话，用 QEMU 模拟 ARM 环境也可以，重点是把加载、匹配、probe、报错这整条链路跑通。

11.3 面试前把经典问题压一遍

面试前一周，把下面这些问题快速过一遍：

• insmod 到设备文件的完整调用过程
• read 和 write 的用户态内核态拷贝
• 字符设备和平台设备的区别
• 自旋锁和互斥锁的选择标准
• 中断下半部为什么存在
• kmalloc/vmalloc/ioremap 的区别
• 阻塞式 read 的实现要点
• oops 信息怎么分析
• I2C 驱动框架三层结构
• 项目里最难忘的调试经历

能压着时间用两三句话说清每个问题，说明知识已经内化了。如果某个问题说一半就开始卡壳，就说明这个知识点还需要回到源码或者实验里补一遍。

12. 十条链之外，真正决定面试结果的准备习惯

回到最开始的问题，27 届秋招的嵌入式驱动岗，面试官为什么喜欢“十连问”？因为这个岗位太容易被简历包装，而不容易被面试伪装。你有没有自己写过驱动、有没有处理过真正的问题、有没有建立起来内核模型和内核机制的整体框架，几轮追问之后基本藏不住。

所以复习的关键不是到处收集“嵌入式八股文”，而是要亲手把代码写出来、把模块加载起来、把调试工具用起来。

12.1 把背诵题变成动手题

字符设备驱动、platform 驱动、中断、等待队列，这些知识点全部可以靠“一个小实验”来验证。每个实验不用复杂，但要能跑通，能看日志，能复现问题。

我自己准备驱动面试时，会把每个问题都改写成“我要在开发板上验证什么”。比如“自旋锁持锁期间能不能睡眠”，不去背答案，而是写一个持自旋锁然后 mdelay 的模块，观察系统行为。这种准备方式慢一点，但印象极深，面试被问到细节时不会慌。

12.2 用复盘代替刷题

刷题本身没有问题，问题是刷完就忘。更有效的方式是每刷一道题，在旁边写下两层内容：一是这个问题问的内核机制是什么，二是如果让我写一段代码验证，我会怎么写。

十条问链全部过完之后，你不需要觉得自己每条都答得完美。面试官心里清楚，能完整讲清楚三四条链、剩下几条能说出思路，已经比大多数候选人扎实。把上面十条链当成一张检查表，一条一条过。能讲清楚原理的，随手写个示例；讲不清楚的，回到实验里再跑一遍。等你能把这十条链都用自己的话讲顺了，秋招面试就不会被“连问”问倒，反而会把追问变成展示自己的机会。