分层设计思想：为什么需要分层？驱动分层架构设计原则与职责划分
说实话，我刚入行那会儿，写驱动就是一把梭。拿到芯片手册，直接对着寄存器开干。一个文件上千行，probe 函数里塞满了硬件初始化、中断注册、文件操作接口。当时觉得挺爽，效率高啊。
直到后来接手一个项目——换了一颗主控芯片，驱动几乎要重写。那时候我才意识到，没有分层的代码，就是给自己挖坑。
为什么非得分这个层？
你想想看，驱动开发最头疼的是什么？是业务逻辑和硬件细节搅在一起。今天要适配一个新板子，明天要换一颗 sensor，后天要改一下数据上报策略。如果所有代码都揉在一块，改一个地方就得动全局。
我总结下来，分层能解决三个核心问题：
- 复用性：核心逻辑写一次，换硬件不用重来
- 可移植性：换平台时只改底层，上层不动
- 可测试性：每一层都能单独测，不用等硬件就绪
核心观点：分层不是炫技，是降低维护成本的手段。说白了，就是让你少加班。
驱动分层架构：三层各自管什么？
我习惯把驱动分成三层：平台层（Platform Layer）、核心层（Core Layer）、HAL 层（Hardware Abstraction Layer）。每一层都有自己的职责，不能越界。
| 层级 | 职责 | 依赖关系 | 典型内容 |
|---|---|---|---|
| 平台层 | 硬件寄存器操作、中断处理、DMA 配置 | 直接操作硬件 | readl/writel、ioremap、中断号 |
| 核心层 | 业务逻辑、数据流管理、状态机 | 调用 HAL 接口 | 数据队列、策略调度、错误处理 |
| HAL 层 | 抽象硬件差异，提供统一接口 | 平台层实现 + 核心层调用 | struct xxx_ops、回调函数表 |
我的习惯：HAL 层只定义接口，不实现具体逻辑。实现交给平台层，调用交给核心层。这样换硬件时，核心层代码一行都不用改。
设计原则：别让层与层之间「谈恋爱」
分层最怕什么？怕层与层之间耦合太紧。我见过有人把 HAL 层的结构体直接传到核心层用，结果换硬件时核心层也得跟着改。这就失去了分层的意义。
几个原则，我每次做架构都会贴在工位上：
- 单向依赖：核心层只能调用 HAL 接口，不能反向依赖平台层
- 接口稳定：HAL 层的 API 一旦定下来，尽量不改
- 数据隔离：每一层都有自己的数据结构，不共用全局变量
- 错误传递：底层错误通过返回值向上传递，上层统一处理
避坑指南：我曾经在一个项目里，核心层直接访问了平台层的寄存器地址。后来换了芯片，寄存器偏移全变了，核心层代码改得面目全非。从那以后，我强制要求所有硬件访问必须经过 HAL 接口。
职责划分：谁该干什么，清清楚楚
我画了一张图，把三层的职责和交互关系展示出来。你看一眼就明白了。
实际案例：一个 SPI 传感器的分层设计
拿一个 SPI 温湿度传感器举例。我做过类似的项目，当时就是这么拆的：
/* ========== HAL 层：定义接口 ========== */
struct sensor_ops {
int (*init)(void);
int (*read_temp)(float *temp);
int (*read_humidity)(float *hum);
int (*deinit)(void);
};
/* ========== 平台层：实现具体硬件操作 ========== */
static int spi_sensor_init(void) {
/* 配置 SPI 时钟、GPIO CS 引脚 */
writel(0x01, SPI_CR1); // 使能 SPI
gpio_set_value(CS_PIN, 1);
return 0;
}
static int spi_sensor_read_temp(float *temp) {
u8 buf[4];
/* 发送读命令，接收数据 */
spi_write_then_read(spi_dev, cmd, 1, buf, 4);
*temp = (buf[0] << 8 | buf[1]) * 0.01;
return 0;
}
static struct sensor_ops spi_ops = {
.init = spi_sensor_init,
.read_temp = spi_sensor_read_temp,
.read_humidity = spi_sensor_read_humidity,
.deinit = spi_sensor_deinit,
};
/* ========== 核心层：业务逻辑 ========== */
static void sensor_work_handler(struct work_struct *work) {
float temp, hum;
/* 只调用 HAL 接口，不关心底层是 SPI 还是 I2C */
ops->read_temp(&temp);
ops->read_humidity(&hum);
/* 数据上报、阈值判断等业务逻辑 */
if (temp > THRESHOLD) {
send_alert(temp);
}
}关键点：核心层里没有出现任何 SPI 相关的代码。如果下次换成 I2C 传感器，只需要重新实现 platform 层的函数，核心层代码直接复用。
分层带来的实际收益
我统计过，采用分层架构后，驱动代码的复用率能提升 60% 以上。具体来说：
- 换芯片：只改平台层，平均 2 天搞定
- 加功能：在核心层加逻辑，不影响已有硬件
- 修 Bug：定位问题范围缩小，不用通读整个驱动
- 团队协作：硬件工程师写平台层，软件工程师写核心层，互不干扰
我的建议：刚开始做分层时，别追求完美。先拆出 HAL 接口，把硬件操作隔离出去。等架构稳定了，再逐步细化核心层的业务逻辑。一步到位反而容易过度设计。
嗯，分层设计说白了就是「把变化隔离起来」。硬件会变，平台会变，但业务逻辑相对稳定。让稳定的部分不依赖变化的部分，这就是分层的本质。