Linux内核调试：详解dev_dbg运行时重启的原理与实战

在 Linux 内核的日志体系中，dev_info、dev_dbg、dev_err 这组函数堪称调试“三剑客”。它们分工明确，为开发者提供了从信息提示到深度调试再到错误追踪的全方位支持。对于开发者而言，灵活掌控 dev_dbg 的启停状态，尤其是在运行时动态激活它，是提升内核与驱动调试效率的关键。本文将深入探讨如何在不重新编译内核或重启系统的前提下，实现 dev_dbg 的“运行时重启”，帮助开发者快速捕获关键运行时日志。

一、dev_info函数

dev_info 是 Linux 内核中用于输出设备相关一般性信息的函数，定义在 <linux/device.h> 头文件中。它基于 printk 实现，但进行了更便捷的封装，默认使用 KERN_INFO 日志级别，旨在告知用户系统运行中的重要事件。其输出信息被发送到内核环形缓冲区，可通过 dmesg 命令查看。

在驱动开发中，dev_info 的核心价值在于输出非错误性的设备关键状态信息，典型应用场景包括设备初始化和状态变更记录。

• 设备驱动初始化：在驱动的 probe 函数中，使用 dev_info 输出设备名称、型号、硬件资源等信息，让开发者快速了解设备初始状态。
• 系统启动关键节点：输出存储设备型号、容量等关键信息，有助于在系统启动异常时快速定位问题。

下面是一个简单的平台设备驱动示例，展示了 dev_info 的使用方法：

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/device.h>
#include <linux/platform_device.h>

// 定义设备驱动结构体
static struct platform_driver my_driver = {
    .probe = my_probe,
    .remove = my_remove,
    .driver = {
         .name = "my_device",
          .owner = THIS_MODULE,
      },
};

// 设备驱动的probe函数，当驱动与设备匹配时调用
static int my_probe(struct platform_device *pdev)
{
    // 获取设备结构体指针
    struct device *dev = &pdev->dev;
    // 使用dev_info输出设备信息
    dev_info(dev, "My device is probed successfully!");
    return 0;
}

// 设备驱动的remove函数，当设备移除时调用
static int my_remove(struct platform_device *pdev)
{
    struct device *dev = &pdev->dev;
    dev_info(dev, "My device is removed.");
    return 0;
}

// 模块加载函数
static int __init my_module_init(void)
{
    // 注册平台驱动
    return platform_driver_register(&my_driver);
}

// 模块卸载函数
static void __exit my_module_exit(void)
{
    // 注销平台驱动
    platform_driver_unregister(&my_driver);
}

module_init(my_module_init);
module_exit(my_module_exit);
MODULE_LICENSE("GPL");

• #include <linux/device.h> 和 #include <linux/platform_device.h> 包含了必要的头文件。
• 在 my_probe 函数中，dev_info(dev, “My device is probed successfully!”); 这行代码会输出设备探测成功的信息，并自动关联设备上下文。
• my_remove 函数在设备移除时输出相应信息。

加载此模块后，通过 dmesg 命令可以看到类似输出：

[    3.452184] my_device: My device is probed successfully!

这条日志清晰表明了设备驱动的状态。

二、dev_dbg函数

dev_dbg 专门用于输出调试级信息，帮助开发者在开发和调试过程中洞察代码执行细节。默认情况下，它的输出是禁用的，以避免影响系统性能和日志可读性。启用 dev_dbg 主要有两种方式：

（1）定义 DEBUG 宏：
在包含 <linux/device.h> 头文件之前，使用 #define DEBUG 来定义 DEBUG 宏。这种方式简单直接，但需要重新编译内核或模块，灵活性较差。

#define DEBUG
#include <linux/device.h>
// 后续代码中可以使用dev_dbg输出调试信息

（2）动态调试机制：
这是实现 运行时控制 的关键。它允许开发者在系统运行时动态开启或关闭 dev_dbg 的输出，而无需重新编译。这需要内核配置中启用 CONFIG_DYNAMIC_DEBUG 选项。在运行时，可以通过 /sys/kernel/debug/dynamic_debug/control 文件来控制。例如，启用指定模块的所有 dev_dbg 输出：

echo ‘module <module_name> +p’ > /sys/kernel/debug/dynamic_debug/control

其中，<module_name> 是模块名，+p 表示启用调试输出，-p 则表示关闭。你还可以更精确地控制：

# 开启某个文件的dev_dbg输出
echo ‘file <filename> +p’ > /sys/kernel/debug/dynamic_debug/control
# 开启某个函数的dev_dbg输出
echo ‘func <func_name> +p’ > /sys/kernel/debug/dynamic_debug/control

动态调试的原理是在内核编译阶段记录所有 dev_dbg 调用点，运行时通过修改控制文件来动态开关，这大大提升了调试的灵活性。对于希望系统化提升调试技能的开发者，可以到 云栈社区的基础与综合板块 交流更多内核与调试原理。

dev_dbg 的典型使用场景是驱动开发调试和内核模块问题排查，它能提供代码执行轨迹和关键变量值。

• 追踪代码执行流程：在关键路径上输出变量值和函数调用信息，验证算法逻辑。
• 排查非严重错误：当函数返回错误参数（如 -EINVAL）或资源分配失败（如 -ENOMEM）时，输出错误上下文，帮助定位根源。

以下是一个模拟 USB 设备驱动数据传输的调试示例：

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/device.h>
#include <linux/usb.h>

// 定义设备结构体
struct my_usb_device {
    struct usb_device *udev;
    // 其他设备相关成员
};

// 数据传输函数
static int my_usb_transfer(struct my_usb_device *dev, char *buf, int len)
{
    int ret;
    // 输出调试信息，记录进入函数和参数值
    dev_dbg(&dev->udev->dev, “Enter my_usb_transfer, len = %d\n”, len);
    // 模拟数据传输
    ret = usb_bulk_msg(dev->udev, usb_sndbulkpipe(dev->udev, 1), buf, len, NULL, 1000);
    if (ret < 0) {
        // 输出调试信息，记录传输失败的错误码
        dev_dbg(&dev->udev->dev, “USB transfer failed, error = %d\n”, ret);
        return ret;
    }
    // 输出调试信息，记录传输成功
    dev_dbg(&dev->udev->dev, “USB transfer success\n”);
    return 0;
}

• dev_dbg(&dev->udev->dev, “Enter my_usb_transfer, len = %d\n”, len); 记录函数调用和参数。
• dev_dbg(&dev->udev->dev, “USB transfer failed, error = %d\n”, ret); 记录失败错误码。

假设模块名为 my_usb_driver，启用调试后执行测试，在 dmesg 中可能看到：

[  123.456789] my_usb_driver: Enter my_usb_transfer, len = 1024
[  123.457890] my_usb_driver: USB transfer failed, error = -EPIPE

根据错误码 -EPIPE（管道破裂），开发者可以进一步检查设备连接或设备端状态。

三、dev_err函数

dev_err 用于输出设备相关的关键错误信息，是错误处理的核心工具。它定义在 <linux/device.h> 中，默认使用 KERN_ERR 日志级别，该级别信息需要开发者高度关注。dev_err 总是默认启用，以确保系统错误能被及时捕获。

在驱动开发的错误处理中，dev_err 用于规范记录错误，为问题定位提供线索。

• 硬件故障记录：如硬盘读写错误时，记录扇区地址和错误类型。
• 资源分配失败：如内存或中断申请失败时，记录错误码和资源信息。

查看 dev_err 日志的主要方法有：

1. 使用 dmesg：dmesg | grep -i err 或 dmesg --level=err。
2. 查看 /var/log/kern.log：tail -f /var/log/kern.log 实时查看。
3. 使用 journalctl（systemd 系统）：journalctl -k | grep -i err。

dev_err 的输出格式示例：

my_driver 0000:01:00.0: Device read error: -EIO

其中包含驱动名、设备地址、错误描述和错误码（-EIO 表示输入输出错误）。

四、为什么要让 dev_dbg 在运行时重启

在 Linux 驱动开发中，实现 dev_dbg 的运行时控制意义重大。传统的调试方式——修改内核配置、重新编译、重启系统——耗时费力，严重拖慢调试节奏。

想象一下，调试 USB 驱动时发现 dev_dbg 输出异常。若按传统流程，你需要熟悉内核配置、经历漫长的编译等待、再重启系统，整个过程可能只为了调整一下调试信息的输出级别。

而运行时重启 dev_dbg 则提供了极高的灵活性。你可以根据实时调试需求，动态控制调试信息的详略程度：测试新功能时开启详细输出；定位关键问题时减少无关信息干扰。这就像为调试工作安装了“加速器”，能显著提升问题定位和解决效率。掌握高效的 调试（Debugging） 方法，是每位系统开发者的必修课。

五、实现 dev_dbg 运行时重启的方法

5.1 使用 dyndbg 控制运行时调试输出

Linux 内核的 dyndbg 机制提供了动态控制调试信息的接口。通过 /sys/kernel/debug/dynamic_debug/control 文件，可以配置特定模块的调试输出。

• 启用模块所有 dev_dbg 输出：

  echo ‘module my_module +p’ > /sys/kernel/debug/dynamic_debug/control

  +p 表示启用 pr_debug() 和 dev_dbg() 输出。

• 关闭输出：

  echo ‘module my_module -p’ > /sys/kernel/debug/dynamic_debug/control

此方法最大的优点是无须重新编译，在运行时即可灵活调整，非常适合需要快速响应的调试场景。

5.2 利用 CONFIG_DYNAMIC_DEBUG 编译选项

这是启用动态调试功能的基石。在编译内核时，必须确保 CONFIG_DYNAMIC_DEBUG=y。如果没有启用此选项，dev_dbg 在默认情况下不会生成任何输出，后续的 dyndbg 控制也无法生效。因此，在定制内核时，务必确认该选项已开启。

5.3 在模块初始化时启用调试输出

部分驱动程序会提供自定义的调试参数，允许在加载模块时控制调试输出。

modprobe my_module debug=1

这要求驱动代码中定义了相应的模块参数，例如：

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/device.h>

static int debug = 0;
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, “Enable debug output”);

static int my_driver_probe(struct device *dev){
    dev_dbg(dev, “Device probe called.\n”);
    return 0;
}

static int my_driver_init(void){
    struct device *my_dev = get_my_device();
    if (debug)
        dev_dbg(my_dev, “Debug mode enabled.\n”);
    return my_driver_probe(my_dev);
}
...

加载模块时使用 modprobe my_module debug=1 即可启用调试输出。这种方法为模块提供了独立的调试开关。

5.4 借助 CONFIG_DEBUG_FS 查看和控制调试信息

有些驱动程序会在 debugfs 文件系统中创建专门的控制节点。首先需要挂载 debugfs：

mount -t debugfs none /sys/kernel/debug

然后通过写入特定节点来控制调试行为，例如：

echo 1 > /sys/kernel/debug/my_module/debug_enable

此方法需要驱动程序本身支持通过 debugfs 进行调试控制，它提供了一个专有的“调试控制台”。熟练运用这些 Bash 命令和脚本（Scripting） 是运维和开发人员的必备技能。

六、解决运行时重启 dev_dbg 可能遇到的问题

6.1 权限问题

尝试修改 /sys/kernel/debug/dynamic_debug/control 时可能因权限不足被拒绝，因为该目录通常需要 root 权限。

解决方案：

• 使用 sudo：sudo echo ‘module e1000 +p’ > /sys/kernel/debug/dynamic_debug/control
• 修改文件权限（慎用）：sudo chmod a+w /sys/kernel/debug/dynamic_debug/control。完成后建议恢复原始权限以保安全。

6.2 内核配置问题

如果内核未开启 CONFIG_DYNAMIC_DEBUG 或 CONFIG_DEBUG_FS，动态调试功能将无法使用。

解决方案：重新编译内核并启用相关配置。

1. 获取内核源代码。
2. 进入源码目录，复制当前配置：cp /boot/config-$(uname -r) .config。
3. 运行 make menuconfig，在 Kernel hacking 子菜单中确保选中 Dynamic debug 和 Debug Filesystem。
4. 执行 make -j$(nproc) 编译内核。
5. 安装并重启新内核：sudo make modules_install install，然后重启系统。

6.3 dev_dbg 无输出

启用后仍无输出，可能原因如下：

1. 条件编译屏蔽：检查代码中是否有 #ifdef DEBUG 等条件编译指令，确保 DEBUG 宏在调试时已被定义（例如在 Makefile 中添加 CFLAGS += -DDEBUG）。
2. 日志级别过滤：dev_dbg 使用 KERN_DEBUG 级别（通常为7）。如果系统控制台日志级别（/proc/sys/kernel/printk 的第一个值）高于此级别，信息会被过滤。可通过 echo 8 > /proc/sys/kernel/printk 允许所有级别输出。
3. 动态调试配置错误：检查命令拼写（模块名、+p参数），并确认 debugfs 已正确挂载：mount | grep debugfs。若未挂载，使用 mount -t debugfs none /sys/kernel/debug 挂载。

七、案例实战：以具体驱动调试为例

假设我们在调试一个名为 eth_driver 的以太网驱动，遇到网络连接异常。我们需要启用其 dev_dbg 输出来定位初始化问题。

操作步骤：

1. 确认配置：确保内核已启用 CONFIG_DYNAMIC_DEBUG。
2. 挂载 debugfs：

   mount -t debugfs none /sys/kernel/debug

3. 启用该模块的调试输出：

   echo ‘module eth_driver +p’ > /sys/kernel/debug/dynamic_debug/control

4. 重新加载驱动以使配置生效：

   rmmod eth_driver
   modprobe eth_driver

5. 查看调试信息：

   dmesg | grep eth_driver

通过上述操作，即可看到驱动初始化过程中 dev_dbg 输出的详细信息，例如硬件探测失败、寄存器初始化错误等，从而快速定位问题根源。