一、日志系统概述：内核日志的作用、printk机制、日志级别详解
大家好，我是你们的老朋友。今天咱们来聊聊内核日志系统。说实话，我刚开始接触内核开发那会儿，觉得日志这东西不就是打印点信息嘛，有啥好研究的？直到有一次，我负责的一个嵌入式设备在产线上频繁死机，串口日志刷得飞快，我却连问题出在哪儿都找不到——嗯，从那以后，我再也不敢小看日志系统了。
1.1 内核日志到底有什么用？
说白了，内核日志就是内核的“黑匣子”。它记录了三类关键信息：
- 调试信息：驱动加载、内存分配、设备枚举等过程的状态
- 错误报告：Oops信息、内核panic、硬件异常等致命问题
- 性能数据：中断延迟、调度延迟、I/O等待时间等
我个人习惯把内核日志比作“手术台上的生命体征监测仪”。没有它，你根本不知道内核内部发生了什么。我记得有一次排查一个USB设备热插拔导致系统挂起的bug，就是靠一条 usb_submit_urb 的日志定位到了问题——那条日志平时看着没啥用，关键时刻能救命。
核心观点：内核日志是系统稳定性的最后一道防线。没有日志，你连问题出在用户态还是内核态都分不清。
1.2 printk 机制：内核的“printf”
printk 是内核中最常用的日志输出函数。它的原型长这样：
int printk(const char *fmt, ...);你可能会问：这不就是 printf 吗？其实不然。printk 有几个关键区别：
- 原子性：printk 可以在中断上下文、自旋锁保护区域等危险环境下调用
- 缓冲机制：输出先写入内核环形缓冲区（ring buffer），再异步刷到控制台
- 日志级别：每条消息都带有一个优先级，控制哪些消息能显示
这里有个坑，我曾经踩过：在中断处理函数里用 printk 打印太多信息，结果导致系统响应变慢。为什么？因为 printk 虽然能在中断里用，但如果日志量太大，它会阻塞中断处理流程。所以我的建议是——生产环境里，中断上下文尽量少用 printk。
小技巧：如果你需要在中断里快速记录信息，可以考虑用 trace_printk 或者直接写 per-CPU 变量，避免环形缓冲区竞争。
1.3 日志级别详解：从 KERN_EMERG 到 KERN_DEBUG
内核定义了8个日志级别，每个级别对应一个数字优先级（数字越小越紧急）：
| 级别宏 | 数字值 | 含义 | 典型场景 |
|---|---|---|---|
KERN_EMERG |
0 | 紧急事件 | 系统即将崩溃 |
KERN_ALERT |
1 | 需要立即处理 | 严重硬件故障 |
KERN_CRIT |
2 | 临界条件 | 驱动加载失败 |
KERN_ERR |
3 | 错误 | I/O操作失败 |
KERN_WARNING |
4 | 警告 | 资源即将耗尽 |
KERN_NOTICE |
5 | 正常但重要 | 设备热插拔 |
KERN_INFO |
6 | 信息 | 驱动版本信息 |
KERN_DEBUG |
7 | 调试信息 | 函数调用跟踪 |
使用方式很简单，在 printk 的格式串前面加上级别宏：
printk(KERN_ERR "DMA transfer failed: status=%d\n", status);
printk(KERN_INFO "eth0: link up at 1000 Mbps\n");
printk(KERN_DEBUG "Entering function foo()\n");这里有个关键点：日志级别决定了消息能否出现在控制台上。内核有一个 console_loglevel 变量，只有级别数值小于该变量的消息才会被打印到控制台。默认情况下，console_loglevel 是 7（显示所有消息），但生产环境通常设为 4（只显示 WARNING 及以上）。
避坑指南：我曾经在生产服务器上看到有人把所有 printk 都写成 KERN_DEBUG，结果系统出问题时控制台一片空白——因为 console_loglevel 设成了 4，而 DEBUG 消息全被过滤掉了。记住：错误信息一定要用 KERN_ERR 或更高级别。
1.4 知识体系总览
下面这张图是我自己总结的内核日志系统核心逻辑，你看一眼就能明白整体架构：
这张图把整个流程串起来了。你从左边看起：驱动或内核子系统调用 printk，printk 把消息格式化后塞进环形缓冲区。然后内核根据 console_loglevel 决定哪些消息能出来，最终送到控制台或者通过 dmesg 让用户看到。
1.5 实战中的几个要点
最后，我分享几个实际项目中的经验：
- 别滥用 KERN_DEBUG：调试完记得删掉或改成 KERN_INFO，否则生产环境日志会爆炸
- 环形缓冲区会溢出：默认大小是 16KB，日志太多会覆盖旧消息。我建议在 .config 里把
CONFIG_LOG_BUF_SHIFT设大一点，比如 18（256KB） - 用
dmesg -w实时看日志：这个命令比tail -f /var/log/messages更直接，能看到内核刚吐出来的消息 - 注意 printk 的并发安全：虽然 printk 本身是原子的，但如果多个 CPU 同时写日志，消息可能会交错。内核 4.15 之后引入了
printk_safe机制来缓解这个问题
个人习惯：我一般在驱动开发阶段把 console_loglevel 设成 8（显示所有消息包括 DEBUG），等代码稳定后再改回 4。这样既能充分调试，又不会在生产环境里刷屏。
好了，关于内核日志系统的基本概念就聊到这儿。记住一句话：日志级别选对了，问题定位快十倍。下次咱们再深入聊聊怎么定制自己的日志输出格式，以及如何用 tracepoint 替代 printk 做高性能日志采集。
公众号:蓝海资料掘金营，微信deep3321