printk调试法：日志级别详解、动态调试与缓冲区管理
说到内核调试，printk 绝对是最基础、最常用的手段。我个人习惯把它叫做「内核界的 printf」。你别看它简单，用好了能解决 80% 的驱动问题。今天我们就来聊聊 printk 的那些门道。
一、printk 日志级别详解
printk 和用户空间的 printf 最大的区别，就是它带了一个日志级别。为什么要加级别？说白了，就是让你能控制哪些信息该打印，哪些该闭嘴。
内核定义了 8 个日志级别，从 0 到 7，数字越小越紧急：
| 宏定义 | 级别值 | 含义 | 典型场景 |
|---|---|---|---|
| KERN_EMERG | 0 | 紧急事件 | 系统崩溃前 |
| KERN_ALERT | 1 | 必须立即处理 | 严重硬件故障 |
| KERN_CRIT | 2 | 临界条件 | 驱动初始化失败 |
| KERN_ERR | 3 | 错误 | DMA 传输错误 |
| KERN_WARNING | 4 | 警告 | 资源不足 |
| KERN_NOTICE | 5 | 正常但重要 | 模块加载成功 |
| KERN_INFO | 6 | 信息 | 驱动版本信息 |
| KERN_DEBUG | 7 | 调试信息 | 变量值打印 |
核心要点：printk 的默认控制台日志级别是 4（KERN_WARNING）。也就是说，只有级别 0-3 的信息才会显示在终端上。级别 4-7 的信息会被写入内核日志缓冲区，但不会直接显示。
我在项目中遇到过这样一个坑：调试一个 I2C 驱动时，怎么都看不到 printk 的输出。折腾了半天才发现，我用的全是 KERN_DEBUG 级别，而控制台级别没改。嗯，这里要注意，调试期间可以临时降低控制台级别：
# 查看当前控制台日志级别
cat /proc/sys/kernel/printk
# 输出示例：4 4 1 7
# 分别表示：控制台级别、默认消息级别、最小控制台级别、启动时默认级别
# 临时设置控制台级别为 7（显示所有信息）
echo 7 > /proc/sys/kernel/printk
# 或者用 dmesg 直接查看内核日志缓冲区
dmesg -n 7二、动态调试（Dynamic Debug）
printk 有个问题：一旦编译进内核，不管用不用都会产生开销。你想想看，生产环境里总不能一直开着所有调试信息吧？动态调试就是来解决这个问题的。
动态调试允许你在运行时动态开启或关闭某个文件、某个函数、甚至某一行代码的 printk 输出。前提是编译内核时开启了 CONFIG_DYNAMIC_DEBUG。
我的经验：动态调试是我调试复杂驱动时的首选。它比 printk 灵活得多，而且性能开销几乎可以忽略。
使用方式很简单，通过 debugfs 接口控制：
# 挂载 debugfs
mount -t debugfs none /sys/kernel/debug
# 查看所有动态调试点
cat /sys/kernel/debug/dynamic_debug/control
# 开启某个文件的全部调试信息
echo 'file drivers/i2c/busses/i2c-imx.c +p' > /sys/kernel/debug/dynamic_debug/control
# 开启某个函数的调试信息
echo 'func imx_i2c_xfer +p' > /sys/kernel/debug/dynamic_debug/control
# 开启某一行
echo 'file i2c-imx.c line 123 +p' > /sys/kernel/debug/dynamic_debug/control
# 关闭调试信息（把 +p 换成 -p）
echo 'file i2c-imx.c -p' > /sys/kernel/debug/dynamic_debug/control我曾经调试一个 USB 控制器驱动时，问题出在中断处理函数里。如果用普通 printk，每次中断都打印，系统直接卡死。用动态调试就完美了——只在需要的时候开启那几行代码的打印，问题定位完就关掉。
三、日志缓冲区管理
内核日志缓冲区是一个环形缓冲区，默认大小通常是 128KB 或 256KB。为什么要用环形？因为日志是源源不断的，缓冲区满了就覆盖最旧的数据。
缓冲区管理有几个关键点：
- 查看缓冲区：用
dmesg命令，或者直接读/proc/kmsg - 清空缓冲区：
dmesg -c（清空后重新开始记录） - 调整缓冲区大小：内核启动参数
log_buf_len=1M - 持久化保存：用
dmesg -w实时监控，或者配置 syslog 服务
注意：缓冲区溢出是个常见问题。如果驱动在中断上下文或原子操作中大量调用 printk，缓冲区很快会被填满，导致早期的重要日志被覆盖。我曾经遇到过系统启动时崩溃，但 dmesg 里只有最后几秒的日志，根本找不到根因。
解决这个问题有几个办法：
- 增大缓冲区：在 bootargs 里加
log_buf_len=4M - 使用
printk_ratelimit()限制打印频率 - 关键信息用
KERN_EMERG级别，确保不被覆盖 - 配合
earlyprintk在启动早期就输出到串口
说到 earlyprintk，这玩意儿在调试启动阶段的问题时特别好用。内核还没初始化完，普通 printk 可能还没生效，但 earlyprintk 可以直接往串口写数据：
# 在 bootargs 中添加
earlyprintk=uart8250,io,0x3f8,115200n8
# 或者更简单的
earlyprintk=serial我个人习惯在开发阶段把 printk 级别设到 7，同时开启动态调试。等驱动稳定了，再逐步关掉不必要的输出。这样既保证了调试效率，又不会影响最终产品的性能。
避坑指南：我曾经在一个项目中，同事在中断处理函数里用了 printk(KERN_INFO ...)，结果导致系统响应变慢，网络丢包严重。后来发现是 printk 在中断上下文里触发了调度。记住：中断上下文里尽量用 printk_ratelimited() 或者干脆别用 printk。
最后，我们来看看 printk 调试法的整体知识体系：
printk 看似简单，但用好它需要理解日志级别、动态调试和缓冲区管理这三个维度。我个人建议你从今天开始，在驱动代码里规范使用日志级别，别再清一色用 KERN_INFO 了。调试时优先考虑动态调试，别动不动就加 printk 然后重新编译。嗯，这些习惯养成了，调试效率能翻一倍。