内核调试从printk到eBPF：动态追踪与可观测性实战

干过内核驱动开发的朋友应该都有这种经历：辛辛苦苦写了几百行模块代码，insmod 下去，系统直接给你一个 Panic，屏幕上一堆十六进制寄存器，你盯着那个调用栈，第一反应就是想骂人。内核态调试和用户态完全是两回事，没有 gdb 断点，没有 core dump，甚至连 printf 都得重新学一遍——因为它在这里叫 printk。从最原始的 printk 到 ftrace、kprobe，再到现在的 eBPF，这套 Linux 内核调试技术栈我用过一轮之后，最大的感受是：工具虽然在迭代，但核心思路从来没变——你得先让内核告诉你，它内部到底发生了什么。

这篇文章我打算按我实际排查问题的经验路径来讲，不是按手册顺序罗列。你会看到 printk 这类基础手段的合理打开方式，也会看到动态追踪是怎么一步步把“观测成本”降下来的。适合刚接触内核模块开发的人，也适合那些被诡异内核问题折磨过、想找更系统调试方法的嵌入式或系统开发者。

1. 调试内核为什么这么难：用户态思维在内核态会翻车

1.1 用户态与内核态调试的差异

在用户态写项目，printf 打日志，gdb 打断点，出了问题大不了重启进程，core dump 分析完就完事。但你面对内核的时候，这套方法论基本失效：内核崩溃等于整机宕机，没有进程让你“重启一下”，panic 之后留下的一屏寄存器转储也不像 core dump 那样能恢复出完整上下文。我一开始调驱动的时候，习惯性地想找个断点单步跟，结果发现连“断下来”这个动作本身都很危险——在中断上下文里停下来，系统调度就瘫了。

更重要的是，内核态天然并发。同一段代码可能跑在多个 CPU 核心、中断上下文、软中断、workqueue、进程上下文里，用户态那种单线程单步执行的经验完全不够用。很多诡异的问题只在高负载下出现，等你把调试器挂上去，问题反而消失了。这背后的本质原因是：你无法在不改变内核执行方式的情况下观察它。所以内核调试技术的发展史，本质上就是一部“尽可能少干扰系统、却又能看清系统内部状态”的历史。printk 是最初的答案，它足够简单，但副作用是慢；动态追踪是后来的演进，它做到了“按需插桩”。

1.2 调试内核需要先建立“可观测性”思维

既然内核态不适合实时打断，那就要换一个思路：不是“停下来看”，而是“让它自己把状态留出来”。日志是状态，trace 记录是状态，tracing 目录里的每个开关也是状态。你要做的第一件事，不是学某个具体工具，而是建立一个判断：我想观测的这条路径，允许多大程度的侵入？

拿这个标准去选工具，事情就清楚很多。如果你只是想知道“这个驱动模块有没有加载成功”，printk 是最合适的；如果你想知道“这个函数被谁调用了一万次”，printk 就不行了，因为打一万次日志系统早就被拖垮。这时候该上 ftrace 或者 kprobe。理解了这条分界线，下面这些工具在你眼里就不是一个个孤立功能，而是一条连续的光谱：printk 在最左侧，侵入性最高、信息获取最直接；动态追踪在最右侧，侵入性低、信息可以按需编程。

2. printk：50岁仍能打的基础日志设施

2.1 别再用裸 printk 了：日志级别与优先级过滤

printk 的入口和 printf 类似，但第一个坑就是日志级别。很多内核新手写的模块代码都是 printk("xxx\n") 这样裸用，默认级别落在 KERN_WARNING，最终进 /var/log/kern.log。问题在于，如果这个模块在正常流程里输出大量信息，默认级别会把日志刷到控制台，还会触发 console 的同步输出，性能直接被打折。

正确做法是用 pr_err、pr_warn、pr_info 这类封装，它们各自对应不同级别，而且配合 loglevel 内核参数可以统一控制。比如系统启动参数里加 loglevel=3，就能让低于 KERN_ERR 的消息全部静音。裸 printk 的级别受 /proc/sys/kernel/printk 的当前值影响，这个值在运行过程中可能被守护进程或人为改动，很容易出现“我明明打了日志，怎么控制台看不到”的困惑。所以我的习惯是：能用 pr_xxx 就不用裸函数，这样日志级别的行为是可预期的。

2.2 pr_fmt 与动态调试，printk 的进阶姿势

一个被很多人忽略的技巧是 pr_fmt。在内核模块源码里，通常在头文件包含之后定义：

c复制#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

这样每个 pr_info 的输出都会自动带上模块名。我调驱动时都会加这一行，日志量一大，grep 模块名能省很多时间。这个宏的意义不只是美观，它给了日志一个固定的可过滤标签，配合 dmesg | grep 或者日志采集系统都方便得多。

更高级一点的是 dynamic de