当前位置：首页 > news >正文

驱动开发硬核特训 · Day 10 （理论上篇）：设备模型 ≈ 运行时的适配器机制

news 来源：原创 2025/5/19 4:03:08

🔍

B站相应的视屏教程：
📌 内核：博文+视频 - 总线驱动模型实战全解析
敬请关注，记得标为原始粉丝。

在 Linux 驱动开发中，设备模型（Device Model）是理解驱动架构的核心。而从软件工程的角度看，它与**适配器模式（Adapter Pattern）**之间也存在着惊人的相似性。本文尝试从理论出发，构建“设备模型 ≈ 运行时的适配器机制”的认知，并通过逻辑图与结构分析，将这一理念讲透讲透。

一、适配器模式回顾：统一接口的桥梁

在这里插入图片描述

在软件设计模式中，**适配器模式（Adapter Pattern）**的作用是：将一个类的接口转换成客户端所期待的另一个接口。

目标接口（Target）：客户端期待调用的接口
源接口（Adaptee）：已有的但不兼容的接口
适配器（Adapter）：中间桥梁，让客户端可以透明使用源接口

我们以 USB 转串口为例：

Client（PC） <--> USB接口
                ↓ 适配器
设备（串口芯片） <--> UART接口

在代码中，Adapter 就是包装 Adaptee 的对象，让它“看起来”满足了 Target 接口。

二、Linux 设备模型的运行时角色

Linux 的设备模型其实也完成了“统一接口”的桥接动作：

platform_device / i2c_client 等设备描述结构（相当于 Adaptee）
platform_driver / i2c_driver 等驱动结构（相当于 Adapter）
driver core（驱动核心）通过总线匹配机制连接设备与驱动（Adapter 注册给一个 Bus，用于查找匹配）

当你写下如下代码时：

platform_driver_register(&my_driver);

实际上就是在告诉内核：我有一个驱动，它能适配某些符合匹配条件的设备，请你在运行时自动“配对”他们。

这正是“运行时适配器机制”的体现！

三、匹配机制的本质：驱动适配器为谁服务？

1. 核心概念类比：

软件工程术语	Linux 设备模型
Target接口	驱动模型中的标准接口（probe等）
Adaptee类	各种硬件设备（platform、I2C等）
Adapter适配器	驱动结构体（platform_driver等）
适配者注册	driver_register / i2c_add_driver
自动装配匹配逻辑	总线匹配函数（of_match、id_table）

2. 匹配的流程图：

           ┌────────────┐
           │ 设备树Node │  ←──── 用户定义设备信息
           └────┬───────┘
                │
                ▼
         ┌──────────────┐
         │ platform_device │ ←─── 内核解析设备树，注册
         └────┬──────────┘
              │
              ▼
         ┌──────────────┐
         │  platform_bus │ ←─── 总线负责配对逻辑
         └────┬──────────┘
              │
      probe匹配机制
              │
              ▼
         ┌──────────────┐
         │ platform_driver │ ←── 驱动是适配器
         └──────────────┘

四、为什么说它是“运行时”的适配器？

适配器模式在传统软件设计中通常是编译期设计好适配关系，但在 Linux 驱动中，设备与驱动的绑定是：

在设备注册（如 platform_device）后，在 driver core 的设备链表中查找驱动
或者在驱动注册后，从已知设备中查找与之匹配的设备
依据的是 名字匹配 / compatible 字符串

因此，这是 运行时动态匹配与绑定，它不是写死的关系，而是通过总线模型中的匹配函数灵活控制。

五、多个总线的统一模型：都是适配器

我们常见的 driver 类型：

platform_driver
i2c_driver
spi_driver
usb_driver
pci_driver

它们都继承了一个共同的父结构：

struct device_driver {
    const char *name;
    struct bus_type *bus;
    ...
};

它们都注册给对应的 bus_type。bus_type 就是 Adapter 插口类型的定义者。

换句话说，不同总线驱动之间的差异只是适配规则的差异，核心逻辑是一样的：我声明我能处理什么设备（通过 compatible 或 ID 表），然后内核会自动调用 probe 函数完成初始化。

六、设备模型中的三大核心角色

为了理解更深入，我们整理出设备模型三大核心结构体的适配关系：

设备模型角色	软件设计模式对应	Linux结构体	功能描述
被适配者	Adaptee	`platform_device` / `i2c_client`	硬件描述
适配器	Adapter	`platform_driver` / `i2c_driver`	驱动逻辑
适配管理器	AdapterManager	`bus_type`	匹配规则、注册匹配与解绑回调

这三者构成了一个完整的“运行时适配”生态。

七、适配器模式的优势在驱动模型中的体现

适配器优势	驱动模型的体现
将不兼容接口统一包装	硬件种类繁多，统一由 driver core 适配
解耦：客户端与底层对象分离	用户只关心 probe 中的行为，与具体设备解耦
支持运行时灵活绑定	动态添加/删除驱动与设备都是天然支持的

八、真实场景举例：平台驱动模型

假设你有如下设备树片段：

lcdif1: lcd-controller@32e80000 {
    compatible = "fsl,imx8mp-lcdif1";
    reg = <0x32e80000 0x10000>;
    interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
    ...
};

你注册了如下 platform_driver：

static const struct of_device_id lcdif_match[] = {
    { .compatible = "fsl,imx8mp-lcdif1" },
    { /* sentinel */ }
};

static struct platform_driver lcdif_driver = {
    .probe = lcdif_probe,
    .remove = lcdif_remove,
    .driver = {
        .name = "lcdif",
        .of_match_table = lcdif_match,
    },
};