3. printk 日志级别详解：8 个级别的含义与使用场景

在 Linux 内核调试中，printk 是驱动开发者最常用的“printf”工具。与用户空间的 printf 不同，printk 通过 日志级别（loglevel） 控制消息的紧急程度和输出行为。理解这 8 个级别，是高效过滤内核日志、定位驱动故障的基础。

3.1 8 个日志级别速查表

下表列出了内核源码 <linux/kern_levels.h> 中定义的 8 个级别，从最高紧急度到最低调试信息：

3.2 日志级别过滤机制

内核通过 控制台日志级别（console_loglevel） 决定哪些消息能输出到串口或显示器。默认值通常为 7（显示所有级别），但生产环境常设为 4（只显示 WARNING 及以上）。

过滤规则非常简单：
只有消息级别数值 ≤ 当前 console_loglevel 时，消息才会被打印到控制台。

例如：console_loglevel = 4 时，只有 KERN_EMERG(0) 到 KERN_WARNING(4) 的消息会显示，KERN_NOTICE(5) 及更低级别的消息被静默。

3.3 级别选择最佳实践

在驱动开发中，合理选择日志级别能大幅提升调试效率。以下是经过大量项目验证的推荐策略：

3.3.1 按模块阶段选择

3.3.2 动态调试与编译开关

对于 KERN_DEBUG 级别的消息，建议配合 pr_debug() 或 dev_dbg() 使用，这些宏在编译时可以通过 DEBUG 宏控制是否生效：

#define DEBUG
#include <linux/printk.h>

// 仅在定义了 DEBUG 时，以下消息才会被编译
pr_debug("my_driver: entering ioctl handler\n");
dev_dbg(&pdev->dev, "register value = 0x%08x\n", reg_val);

3.3.3 避免日志风暴

在中断处理函数或高频调用的热路径中，严禁使用 printk（即使是 KERN_DEBUG）。如果必须调试，使用以下限速机制：

• rate limiting： 使用 pr_err_ratelimited()、dev_warn_ratelimited() 等宏，防止同一消息在短时间内重复刷屏。
• 条件打印： 只在特定错误码或状态变化时打印，避免每帧都输出。
• 统计计数： 在热路径中只递增计数器，在定时器或工作队列中汇总打印。

// 错误示例：中断中每包都打印
irqreturn_t my_irq_handler(int irq, void *dev_id) {
    printk(KERN_DEBUG "my_driver: interrupt received\n");  // 危险！高频刷屏
    // ... 处理中断
    return IRQ_HANDLED;
}

// 正确示例：使用限速打印
irqreturn_t my_irq_handler(int irq, void *dev_id) {
    if (unlikely(some_error_condition)) {
        pr_err_ratelimited("my_driver: error condition detected\n");
    }
    // ... 处理中断
    return IRQ_HANDLED;
}

3.4 日志级别与 syslog 的映射

内核日志最终会通过 klogd 或 journald 传递到用户空间的 syslog 系统。了解映射关系有助于统一分析：

3.5 常见陷阱与避坑指南

• 陷阱1：忘记加日志级别前缀 —— 如果 printk("message\n") 没有指定级别，内核会使用默认级别 DEFAULT_MESSAGE_LOGLEVEL（通常是 4，即 KERN_WARNING）。这会导致调试信息意外出现在控制台上。
• 陷阱2：在中断上下文使用 printk 不加限速 —— 中断处理函数中频繁调用 printk 会导致系统响应变慢，甚至触发看门狗复位。
• 陷阱3：生产环境保留大量 KERN_DEBUG —— 调试完成后未关闭 DEBUG 宏，导致日志缓冲区被调试信息填满，关键错误被覆盖。
• 陷阱4：混淆 pr_info 与 pr_debug —— pr_info 总是被编译，而 pr_debug 受 DEBUG 宏控制。在性能敏感的路径中，应优先使用 pr_debug。