3. Linux内核中的Watchdog框架：内核Watchdog子系统架构，/dev/watchdog接口详解

好，咱们进入正题。这一节我打算聊聊Linux内核里的Watchdog框架。说实话，很多做应用层的朋友可能从来没碰过这块，但车载系统里，这玩意儿是保命的底线。

内核的Watchdog子系统，说白了就是一套标准化的看门狗管理机制。它把硬件看门狗的操作抽象成统一的接口，让上层应用不用关心底层用的是哪家芯片、什么型号。我个人觉得，这是Linux内核设计里非常漂亮的一个模块——麻雀虽小，五脏俱全。

3.1 内核Watchdog子系统的分层架构

先看整体架构。内核Watchdog子系统分三层：

  • 底层：硬件驱动层 —— 直接操作看门狗定时器寄存器
  • 中间层：Watchdog核心层 —— 提供通用框架和接口
  • 上层：用户空间接口层 —— 通过字符设备暴露给应用

嗯，这里要注意，核心层在 drivers/watchdog/ 目录下，关键文件是 watchdog_core.c 和 watchdog_dev.c。前者负责注册管理，后者负责设备文件操作。

核心数据结构：每个看门狗设备对应一个 struct watchdog_device，里面包含了超时时间、操作函数集、状态标志等。

// 内核源码中的核心结构体（简化版）
struct watchdog_device {
    int id;                     // 设备ID
    struct device *parent;      // 父设备
    const struct watchdog_info *info;    // 设备信息
    const struct watchdog_ops *ops;      // 操作函数集
    unsigned int timeout;       // 超时时间（秒）
    unsigned int min_timeout;   // 最小超时
    unsigned int max_timeout;   // 最大超时
    unsigned long status;       // 状态标志
    // ... 省略其他字段
};

我在项目中遇到过一个问题：某款车规级SoC的看门狗最小超时是1秒，但应用层配置了500ms。结果驱动直接报错返回，系统没喂狗成功，最后复位了。所以啊，配置前一定要查清楚硬件支持的区间。

3.2 操作函数集：watchdog_ops

每个看门狗驱动都要实现一组回调函数，定义在 struct watchdog_ops 里：

函数指针 作用 我的经验
start 启动看门狗定时器 注意启动后要立即喂一次狗
stop 停止看门狗 有些硬件不支持停止，只能设置超长超时
ping 喂狗操作（也叫kicking） 我习惯在ping里加个计数器，方便调试
set_timeout 设置超时时间 返回值是实际设置的超时，可能和请求值不同
get_timeleft 获取剩余时间 不是所有硬件都支持，不支持就返回-EOPNOTSUPP

小技巧：写驱动时，set_timeout 函数最好返回实际设置的超时值。因为硬件可能只能设置离散的几个档位，比如只能设10秒、30秒、60秒。你传个25秒进去，它可能给你设成30秒。应用层需要知道这个真实值。

3.3 /dev/watchdog 接口详解

用户空间操作看门狗，主要通过 /dev/watchdog 这个字符设备。它遵循标准的open/close/ioctl模式。我刚开始接触时觉得很简单，后来踩了几个坑才发现门道不少。

3.3.1 基本操作流程

// 最简单的喂狗程序
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <linux/watchdog.h>

int main() {
    int fd = open("/dev/watchdog", O_RDWR);
    if (fd < 0) {
        perror("open");
        return -1;
    }

    // 喂狗循环
    while (1) {
        write(fd, "\0", 1);  // 喂狗操作
        sleep(5);            // 每5秒喂一次
    }

    close(fd);
    return 0;
}

这段代码看起来简单，但有个大坑——close(fd) 的行为。默认情况下，关闭设备文件会触发看门狗停止。如果硬件不支持停止，那就直接复位系统！

警告：千万不要在生产代码里直接close看门狗设备。除非你明确知道自己在做什么，否则close操作可能导致系统立即复位。

3.3.2 关键ioctl命令

真正灵活的操作靠ioctl。常用的命令有这些：

#include <linux/watchdog.h>

// 获取设备信息
struct watchdog_info info;
ioctl(fd, WDIOC_GETSUPPORT, &info);
// info中包含了：固件版本、设备标识、支持的功能位图

// 获取/设置超时时间
int timeout = 30;
ioctl(fd, WDIOC_SETTIMEOUT, &timeout);  // 设置超时
ioctl(fd, WDIOC_GETTIMEOUT, &timeout);  // 获取当前超时

// 获取剩余时间
int timeleft;
ioctl(fd, WDIOC_GETTIMELEFT, &timeleft);

// 喂狗（等同于write操作）
int dummy = 0;
ioctl(fd, WDIOC_KEEPALIVE, &dummy);

// 设置/获取预超时（pretimeout）—— 高级功能
int pretimeout = 5;
ioctl(fd, WDIOC_SETPRETIMEOUT, &pretimeout);

我个人习惯在应用启动时先调用 WDIOC_GETSUPPORT，看看硬件支持哪些功能。比如有些芯片支持 WDIOF_PRETIMEOUT 标志，意味着可以在真正超时前发出一个信号，给系统一个最后的抢救机会。

3.3.3 Magic Close 机制

为了解决close导致复位的问题，内核引入了Magic Close机制。说白了就是：在close之前，先写入一个特殊字符 'V'，告诉内核「我是正常关闭，别复位」。

// 正确的关闭方式
write(fd, "V", 1);  // 写入Magic字符
close(fd);          // 安全关闭

如果不写这个 'V' 就直接close，内核会认为应用异常退出，直接触发硬件复位。嗯，这里要注意，Magic Close需要在驱动中显式启用，不是所有驱动都支持。

3.4 内核中的Watchdog状态机

每个看门狗设备在内核里都有一个状态机。我画个简化的状态流转：

  • WDIOF_ACTIVE —— 设备已打开，正在运行
  • WDIOF_KEEPALIVEPING —— 正在被喂狗
  • WDIOF_MAGICCLOSE —— 允许Magic Close
  • WDIOF_PRETIMEOUT —— 预超时触发

曾经有个项目，应用层开了两个线程同时操作 /dev/watchdog，结果状态机乱了，一个线程close了设备，另一个线程还在喂狗，但喂的是空气。系统最后复位了。所以我的建议是：整个系统只有一个进程负责看门狗管理，其他模块通过IPC通知这个进程。

3.5 实际项目中的配置建议

车载Linux系统里，我一般这样配置看门狗：

  1. 超时时间设为核心业务周期的3倍。比如核心监控线程每2秒跑一次，超时就设6秒。留出余量应对瞬时负载。
  2. 启用预超时功能。如果硬件支持，预超时设为超时的一半。预超时触发时，内核会发送 SIGIO 信号给应用，应用可以做最后的日志保存。
  3. 使用独立的监控进程。这个进程不干别的，只负责喂狗和监控其他关键进程的心跳。
  4. 开机自动启动。在init脚本里尽早打开看门狗，防止启动过程中死锁。

避坑指南：我曾经在一个项目里把看门狗超时设得太短（1秒），结果系统刚启动时，文件系统还没挂载完，监控进程启动晚了，直接触发复位。后来我把超时改成了10秒，并在内核启动参数里加了 watchdog_thresh=10，问题解决。

3.6 调试技巧

调试看门狗问题，我常用的方法：

  • 查看 /proc/watchdog 或 /sys/class/watchdog/ 下的信息
  • 用 watchdog -t 10 /dev/watchdog 命令行工具测试
  • 内核开启 CONFIG_WATCHDOG_NOWAYOUT —— 这个选项会让看门狗在系统panic时也不停止，适合车载场景
  • 在驱动里加调试打印，每次喂狗时打印时间戳

好了，这一节的内容就到这里。下一节我会讲用户空间看门狗守护进程的设计，包括如何实现多级监控、如何优雅处理预超时信号。到时候咱们再细聊。

← 上一章 📖 返回目录 下一章 →