3. 驱动代码质量维度

Linux 内核驱动运行在内核态，一旦出现缺陷，轻则导致设备无法工作，重则引发 oops、panic 或数据损坏。因此，评价一份驱动代码的质量，不能只看“功能是否跑通”，而要从多个维度综合衡量。本节把驱动代码质量归纳为六个核心维度：可读性、可维护性、可移植性、并发安全、错误处理、资源管理。它们相互关联，共同决定驱动能否长期稳定地存在于内核主线或产品代码中。

一、核心原理：六个维度分别衡量什么

可读性关注代码是否容易被他人（以及几个月后的自己）理解。内核社区对命名、缩进、注释、函数长度有明确约定，例如 checkpatch.pl 会检查行宽、空格、括号风格。可读性差的代码往往表现为：函数过长、变量名含糊（如 tmp、data1）、魔法数字遍布、缺少必要的注释说明硬件行为。

可维护性关注修改成本。好的驱动应当职责单一、模块边界清晰、错误路径集中、日志可定位。若一个 probe() 函数里混杂了寄存器初始化、中断注册、字符设备注册、sysfs 创建和电源管理，那么每次需求变更都要在长函数中反复寻找插入点，回归风险极高。

可移植性关注代码能否在不同架构、不同内核版本、不同板级配置下编译和运行。典型问题包括：直接使用物理地址、依赖特定字节序、调用已废弃的 API、硬编码 GPIO 编号、假设 sizeof(int) 固定。内核提供了 readl()/writel()、cpu_to_le32()、设备树、devm_* 等机制来提升可移植性。

并发安全关注多核、中断、软中断、工作队列、用户进程同时访问共享数据时是否会产生竞态。驱动中常见的共享对象包括设备结构体、环形缓冲区、状态标志、链表。保护手段有自旋锁、互斥锁、原子变量、RCU、完成量等，选择取决于上下文是否可睡眠。

错误处理关注失败路径是否被正确识别、传播和恢复。内核 API 大量返回 ERR_PTR()、NULL、负错误码，驱动必须逐一判断，不能忽略返回值。错误处理不当会导致空指针解引用、资源泄漏、设备状态不一致。

资源管理关注内存、中断、时钟、regulator、GPIO、DMA、文件描述符等资源是否在成功时申请、失败时释放、卸载时回收。Linux 提供 devm_* 托管接口，能显著降低 remove() 路径的遗漏风险，但并非所有资源都被托管，仍需人工核对。

二、方法流程：如何逐维度审查驱动代码

在实际工程中，可以按以下流程对一份驱动进行质量审查：

1. 静态检查：先运行 checkpatch.pl --strict 和 sparse，捕获风格、类型、地址空间标注问题。
2. 可读性走查：检查函数长度、命名一致性、注释是否解释“为什么”而非“做什么”。
3. 可维护性走查：确认 probe/remove 是否对称，错误路径是否集中，日志是否带设备名。
4. 可移植性走查：搜索硬编码地址、__raw_readl、废弃 API、架构相关头文件。
5. 并发安全走查：列出所有共享数据，标注访问上下文，确认锁的覆盖范围与顺序。
6. 错误处理与资源管理走查：逐行检查返回值，核对每个申请是否有对应释放，优先使用 devm_*。

三、案例与场景：一个字符设备驱动的质量对照

下面是一段存在多个质量问题的驱动片段：

static int my_probe(struct platform_device *pdev)
{
    int ret;
    struct my_dev *d;
    void __iomem *base;

    base = ioremap(0x12340000, 0x1000);   /* 硬编码物理地址 */
    d = kmalloc(sizeof(struct my_dev), GFP_KERNEL);
    if (!d)
        return -ENOMEM;

    d->base = base;
    spin_lock(&d->lock);                  /* 未初始化锁 */
    ret = request_irq(10, my_isr, 0, "my", d);  /* 硬编码中断号 */
    if (ret)
        return ret;                        /* 泄漏 d 和 base */

    cdev_init(&d->cdev, &my_fops);
    cdev_add(&d->cdev, d->devno, 1);
    return 0;
}

这段代码在六个维度上都有明显缺陷：可读性上缺少注释和错误日志；可维护性上 probe 承担过多职责；可移植性上硬编码地址和中断号；并发安全上锁未初始化；错误处理上忽略 cdev_add 返回值；资源管理上 request_irq 失败后未释放 d 和 base。改进方向是使用设备树获取资源、用 devm_kzalloc、devm_ioremap_resource、devm_request_irq，并统一错误路径。

四、误区与复盘：常见质量陷阱

复盘时可以问三个问题：这段代码换一个人能看懂吗？换一个内核版本能编译吗？在中断和用户进程同时访问时还正确吗？如果答案是否定的，就说明对应维度仍需加强。驱动质量不是一次性的检查，而是贯穿设计、编码、评审、测试和长期维护的持续过程。