Linux驱动高级工程师高阶面试宝典 - 第2节

图：内核驱动基础面试问题回答流程图，按顺序展开，最后分支选择 printk 或 proc/seq

问：如何编写和编译一个简单的内核模块？

🎯 面试官考察点

• 是否理解内核模块的基本结构（init/exit、MODULE_LICENSE等）
• 是否熟悉内核Kbuild/Makefile编译体系
• 是否清楚模块与应用程序的区别（运行空间、API限制）

📐 回答框架

1. 先说明模块结构：module_init/module_exit + 许可证
2. 解释编译方式：使用内核源码的Makefile，通过obj-m + make -C
3. 简要演示一个 hello 模块的.c和Makefile
4. 强调注意点：内核版本兼容、KERNELRELEASE判断

✍️ 简短示例回答

“先写入口函数 module_init(hello_init) 和出口 module_exit(hello_exit)，加上 MODULE_LICENSE("GPL")。编译用 Makefile：obj-m := hello.o，再 make -C /lib/modules/$(uname -r)/build M=$(PWD) modules。生成的 hello.ko 即可用 insmod 加载，dmesg 看到打印。”

❓ 可能追问

• 如果内核源码没有安装，如何编译模块？
• 模块参数如何传递（module_param）？
• 如何交叉编译模块？

⚠️ 避坑提醒

Makefile 中:=与+=的选择；内核版本与目标源码目录必须匹配；不要直接写死路径，用$(shell uname -r)。

问：insmod 和 modprobe 有什么区别？加载失败时如何排查？

🎯 面试官考察点

• 是否熟悉模块依赖与自动解析机制
• 是否掌握常见加载失败原因的排查思路
• 是否了解/var/log/kern.log和dmesg的使用

📐 回答框架

1. 明确差异：insmod直接加载目标文件，不处理依赖；modprobe自动处理依赖并加载
2. 排查步骤：先 dmesg | tail 看内核日志；检查模块是否符号冲突或版本不匹配
3. 常见原因：未满足依赖、Module.symvers缺失、版本魔法号不一致
4. 高级技巧：使用 modinfo 查看模块信息，lsmod 确认当前模块

✍️ 简短示例回答

“insmod 简单但需手动解决依赖；modprobe 会自动加载依赖模块。加载失败时立刻执行 dmesg | grep -i error，看具体错误：比如 Unknown symbol 说明缺少符号，需先加载依赖模块。再用 modinfo 确认模块参数的正确性。”

❓ 可能追问

• 如果自定义模块依赖其他模块，如何生成 modules.dep？
• 模块卸载时 rmmod 和 modprobe -r 有何不同？
• 如何通过 /sys/module 查看模块参数？

⚠️ 避坑提醒

不要忽略 modprobe 会搜索 /lib/modules/$(uname -r) 目录；如果模块不在默认路径，需使用 insmod 并指定完整路径；注意 symbol versioning 导致加载失败。

问：printk 的日志级别有哪些？如何在生产环境控制调试信息输出？

🎯 面试官考察点

• 是否理解 printk 的 8 个日志等级（KERN_EMERG ~ KERN_DEBUG）
• 是否知道 /proc/sys/kernel/printk 的四个值含义
• 是否有动态调整调试信息的实践（dynamic_debug 或自定义宏）

📐 回答框架

1. 列举常用等级：KERN_ERR、KERN_WARNING、KERN_INFO、KERN_DEBUG
2. 解释控制机制：/proc/sys/kernel/printk 的四个字段（控制台级别、默认级别、最小级别、引导级别）
3. 生产环境策略：用pr_debug + dynamic_debug 或 #ifdef DEBUG 编译开关
4. 推荐使用 dev_dbg/dev_err 等设备相关打印，便于过滤

✍️ 简短示例回答

“printk 有 0~7 共 8 个等级，常用 KERN_ERR（3）和 KERN_INFO（6）。生产环境通过 echo "8 4 1 7" > /proc/sys/kernel/printk 关闭低级别打印。更推荐用 pr_debug，配合 dynamic_debug 模块运行时开关调试信息，不影响线上性能。”

❓ 可能追问

• printk 与 dev_crit 系列函数的区别？
• 如何通过 syslogd 或 systemd-journald 持久化内核日志？
• 动态调试（dyndbg）如何按文件或函数过滤？

⚠️ 避坑提醒

生产环境慎用 printk(KERN_DEBUG ...) 如果未调整阈值会大量输出；dynamic_debug 需内核配置 CONFIG_DYNAMIC_DEBUG，且需在模块编译时加上 ccflags-y := -DDEBUG。

驱动内核对设备状态的内存级监控与诊断系统

业务背景

某数据中心网络加速卡在高速收发包场景下，用户态工具无法实时感知驱动内部队列深度、中断次数和内存池状态。需要在/下暴露内核态实时数据，且要求读取开销极低、支持大量节点并发访问。

规模指标

• 模块代码行数：约 2500 行 C
• 暴露的 proc/seq 文件数量：12 个
• 单文件数据量：小于 4KB，读取延迟 < 5μs
• 并发读取压力：200+ 用户线程同时 cat，无锁竞争

技术栈

• 内核版本：4.19 LTS
• 接口：seq_file + single_open + proc_create
• 同步机制：RCU + percpu_counter
• 调试工具：trace_printk + dyndbg

核心难点

• 如何在内核态提供无锁读访问（使用 RCU）
• 大量 proc 文件创建对 proc_fs 资源的影响
• 用户空间反复 lseek 导致的 seq_file 重读问题

面试高频追问

1. 为什么选择 seq_file 而不是直接 write/read 到 proc 文件？
2. 如何确保 seq_file 的 next 函数不会因为数据变化而越界？
3. 当多个 CPU 同时读同一个 seq_file，内核如何避免数据错乱？
4. 如果数据量超过 PAGE_SIZE，seq_file 的分页机制如何处理？

可迁移回答话术

• 优势对比：“seq_file 专为内核大块数据导出设计，自动处理跨页封装，避免自己实现 read+offset 逻辑，比直接 proc_read 更安全简洁。”
• 并发保护：“核心字段使用 percpu_counter 计算总量，读端用 RCU 访问链表，seq_file 的 next 中无需加锁，依赖 stop 正确释放读锁。”
• 性能调优：“每个 seq_file 实例独立，用户 cat 后断开，不遗留锁资源；使用 single_open 简化单次快照输出，避免累加偏移。”
• 调试组合：“配合 trace_printk 可跟踪 seq_file 的 start/next/stop 调用频率，dyndbg 开关文件级日志。”

图：项目案例的 STAR 表达图，突出核心行动与成果