在嵌入式开发中你一定见过很多驱动代码里都有一个ops结构体。很多人觉得这是 “写法花哨”但实际上它的核心作用是把接口稳定下来让上层代码不用关心底层硬件的具体实现。今天我们就来深入聊聊这个设计模式。一、核心思想接口稳定实现分离ops结构体的本质不是“炫技”而是把动作和数据分离。我们将设备的操作open、read、write、close等放进ops表让上层只依赖统一的接口底层实现可以灵活替换。// 设备操作表函数指针集合 struct driver_ops { int (*open)(struct device *dev); int (*read)(struct device *dev, void *buf); int (*write)(struct device *dev, void *buf, int len); void (*close)(struct device *dev); };二、上层只认识动作不关心硬件是谁上层代码只需要调用统一的接口不需要关心底层是UART、SPI还是I2C// 上层调用示例 dev-ops-open(dev); dev-ops-read(dev, buf); dev-ops-write(dev, data, len); dev-ops-close(dev);这样上层代码只认识open、read、write、close这些动作底层硬件的具体实现不会暴露给主流程。三、不同硬件把实现挂到各自的 ops 表不同硬件的实现只需要挂到各自的ops表中驱动类型ops表指针实现函数UARTuart_opsuart_open、uart_readSPIspi_opsspi_open、spi_xferI2Ci2c_opsi2c_open、i2c_xfer底层实现示例// UART设备实现 static int uart_open(struct device *dev) { // UART初始化逻辑 return 0; } static int uart_read(struct device *dev, void *buf) { // UART读取逻辑 return 0; } static const struct driver_ops uart_ops { .open uart_open, .read uart_read, .write uart_write, .close uart_close, }; // SPI设备实现 static int spi_open(struct device *dev) { // SPI初始化逻辑 return 0; } static int spi_xfer(struct device *dev, void *buf) { // SPI传输逻辑 return 0; } static const struct driver_ops spi_ops { .open spi_open, .read spi_xfer, .write spi_xfer, .close spi_close, };四、框架只存指针调用时像查表框架只需要保存ops指针调用时就像查表一样const struct driver_ops *ops dev-ops; ops-open(dev); // 自动调用对应的实现这样公共流程不需要再写一串if (type UART)只需要沿着ops指针走到真正的实现。五、边界清晰状态在 device动作在 ops我们需要明确两个边界device结构体保存设备的状态、私有数据、正在运行的信息ops结构体保存设备的动作、入口、应该怎么调用struct device { void *state; // 设备状态、私有数据 const struct driver_ops *ops; // 操作表指针 };六、初始化挂表运行时走回调入口初始化时我们把ops表挂到设备上运行时通过回调入口调用// 初始化时挂表 static const struct driver_ops uart_ops { .open uart_open, .read uart_read, }; dev-ops uart_ops; // 运行时回调入口 dev-ops-open(dev);七、新增驱动时不改流程只补表和函数新增驱动时我们不需要修改主流程只需要补一张ops表和一组实现函数// 新增传感器驱动 static const struct driver_ops sensor_ops { .open sensor_open, .read sensor_read, .write sensor_write, .close sensor_close, }; // 注册到框架 register_driver(sensor_ops);这样新增驱动时不会影响主流程代码更稳定、更易扩展。八、总结ops结构体是嵌入式C语言中非常实用的设计模式它的核心价值在于接口稳定上层只依赖统一的接口底层实现可以灵活替换低耦合主流程和具体设备实现分离修改一处不会影响全局高扩展新增驱动时只需要补表和函数不需要修改主流程易维护代码结构清晰数据和操作分离每个设备的实现独立在实际开发中我们可以根据具体需求灵活运用这种设计模式让你的驱动代码更稳定、更易扩展、更易维护。如果你觉得这篇文章对你有帮助欢迎关注我带你把嵌入式C写得稳定、清楚、可维护。
42.嵌入式C语言进阶：为什么驱动里总要有个 `ops` 结构体？
在嵌入式开发中你一定见过很多驱动代码里都有一个ops结构体。很多人觉得这是 “写法花哨”但实际上它的核心作用是把接口稳定下来让上层代码不用关心底层硬件的具体实现。今天我们就来深入聊聊这个设计模式。一、核心思想接口稳定实现分离ops结构体的本质不是“炫技”而是把动作和数据分离。我们将设备的操作open、read、write、close等放进ops表让上层只依赖统一的接口底层实现可以灵活替换。// 设备操作表函数指针集合 struct driver_ops { int (*open)(struct device *dev); int (*read)(struct device *dev, void *buf); int (*write)(struct device *dev, void *buf, int len); void (*close)(struct device *dev); };二、上层只认识动作不关心硬件是谁上层代码只需要调用统一的接口不需要关心底层是UART、SPI还是I2C// 上层调用示例 dev-ops-open(dev); dev-ops-read(dev, buf); dev-ops-write(dev, data, len); dev-ops-close(dev);这样上层代码只认识open、read、write、close这些动作底层硬件的具体实现不会暴露给主流程。三、不同硬件把实现挂到各自的 ops 表不同硬件的实现只需要挂到各自的ops表中驱动类型ops表指针实现函数UARTuart_opsuart_open、uart_readSPIspi_opsspi_open、spi_xferI2Ci2c_opsi2c_open、i2c_xfer底层实现示例// UART设备实现 static int uart_open(struct device *dev) { // UART初始化逻辑 return 0; } static int uart_read(struct device *dev, void *buf) { // UART读取逻辑 return 0; } static const struct driver_ops uart_ops { .open uart_open, .read uart_read, .write uart_write, .close uart_close, }; // SPI设备实现 static int spi_open(struct device *dev) { // SPI初始化逻辑 return 0; } static int spi_xfer(struct device *dev, void *buf) { // SPI传输逻辑 return 0; } static const struct driver_ops spi_ops { .open spi_open, .read spi_xfer, .write spi_xfer, .close spi_close, };四、框架只存指针调用时像查表框架只需要保存ops指针调用时就像查表一样const struct driver_ops *ops dev-ops; ops-open(dev); // 自动调用对应的实现这样公共流程不需要再写一串if (type UART)只需要沿着ops指针走到真正的实现。五、边界清晰状态在 device动作在 ops我们需要明确两个边界device结构体保存设备的状态、私有数据、正在运行的信息ops结构体保存设备的动作、入口、应该怎么调用struct device { void *state; // 设备状态、私有数据 const struct driver_ops *ops; // 操作表指针 };六、初始化挂表运行时走回调入口初始化时我们把ops表挂到设备上运行时通过回调入口调用// 初始化时挂表 static const struct driver_ops uart_ops { .open uart_open, .read uart_read, }; dev-ops uart_ops; // 运行时回调入口 dev-ops-open(dev);七、新增驱动时不改流程只补表和函数新增驱动时我们不需要修改主流程只需要补一张ops表和一组实现函数// 新增传感器驱动 static const struct driver_ops sensor_ops { .open sensor_open, .read sensor_read, .write sensor_write, .close sensor_close, }; // 注册到框架 register_driver(sensor_ops);这样新增驱动时不会影响主流程代码更稳定、更易扩展。八、总结ops结构体是嵌入式C语言中非常实用的设计模式它的核心价值在于接口稳定上层只依赖统一的接口底层实现可以灵活替换低耦合主流程和具体设备实现分离修改一处不会影响全局高扩展新增驱动时只需要补表和函数不需要修改主流程易维护代码结构清晰数据和操作分离每个设备的实现独立在实际开发中我们可以根据具体需求灵活运用这种设计模式让你的驱动代码更稳定、更易扩展、更易维护。如果你觉得这篇文章对你有帮助欢迎关注我带你把嵌入式C写得稳定、清楚、可维护。
