驱动框架与模型：从WDM到Linux平台驱动
大家好，我是你们的老朋友。今天我们来聊聊驱动框架与模型这个话题。说实话，我刚入行那会儿，面对WDM、KMDF、UMDF这些缩写，头都大了。后来踩了不少坑，才慢慢理清它们之间的关系。今天我就把这些经验分享给你。
WDM驱动模型：Windows驱动的老前辈
WDM，全称Windows Driver Model，是微软在Windows 98/2000时代推出的驱动框架。说白了，它定义了一套标准接口，让硬件厂商能写出兼容不同Windows版本的驱动。
WDM的核心思想是分层和IRP（I/O请求包）。每个驱动都处理IRP，然后传给下一层。我刚开始写WDM驱动时，最头疼的就是IRP的处理流程。你想想看，一个读写请求从应用层下来，要经过文件系统驱动、卷管理驱动、磁盘驱动，最后才到你的硬件驱动。任何一个环节出错，整个系统都可能蓝屏。
WDM驱动的主要特点：
- 支持即插即用（PnP）和电源管理
- 使用IRP作为通信机制
- 驱动对象、设备对象、功能设备对象（FDO）和物理设备对象（PDO）
- 需要处理AddDevice、DriverEntry、Dispatch等回调函数
这里我画了一张WDM驱动的分层结构图，帮你理解各个组件的关系：
我的经验：写WDM驱动时，一定要处理好IRP的完成例程。我曾经因为忘记调用IoCompleteRequest，导致系统挂起，排查了整整两天。嗯，从那以后我写IRP处理代码都会反复检查。
WDF驱动模型：微软的现代化方案
WDF（Windows Driver Framework）是微软在Vista之后推出的新一代驱动框架。它分两种：KMDF（内核模式）和UMDF（用户模式）。说白了，WDF就是对WDM的封装，帮你处理了很多底层细节。
我个人习惯用KMDF写内核驱动，因为它提供了更高级的抽象。你不需要手动处理IRP的同步、取消、队列管理，框架都帮你搞定了。举个例子，在WDM中你要写几十行代码处理读写请求，在KMDF中可能只需要几行。
KMDF vs UMDF：怎么选？
| 特性 | KMDF | UMDF |
|---|---|---|
| 运行模式 | 内核模式 | 用户模式 |
| 崩溃影响 | 蓝屏 | 仅进程崩溃 |
| 性能 | 高 | 中等（有上下文切换） |
| 调试难度 | 高（需要WinDbg） | 低（可用VS调试） |
| 适用场景 | 高性能设备、存储、网络 | USB、传感器、打印机 |
我建议：如果是做存储或网络驱动，用KMDF。如果是USB或传感器这类对性能要求不高的设备，UMDF更安全。我曾经在一个项目中用UMDF写USB驱动，调试起来比KMDF轻松太多了。
注意：UMDF驱动不能直接访问硬件，所有硬件操作都要通过内核模式的双向通信来完成。这意味着你的驱动设计要更复杂一些。
Linux字符设备驱动框架
Linux的驱动框架和Windows完全不同。字符设备驱动是最基础的一种，也是我最早接触的Linux驱动类型。它的核心就是file_operations结构体，里面定义了open、read、write、ioctl等回调函数。
来看一个最简单的字符设备驱动框架：
#include <linux/module.h>
#include <linux/fs.h>
#include <linux/cdev.h>
static int my_open(struct inode *inode, struct file *file) {
printk(KERN_INFO "Device opened\n");
return 0;
}
static ssize_t my_read(struct file *file, char __user *buf,
size_t len, loff_t *off) {
// 读取逻辑
return 0;
}
static struct file_operations my_fops = {
.owner = THIS_MODULE,
.open = my_open,
.read = my_read,
};
static int __init my_init(void) {
// 注册字符设备
register_chrdev(0, "my_device", &my_fops);
return 0;
}
static void __exit my_exit(void) {
unregister_chrdev(0, "my_device");
}
module_init(my_init);
module_exit(my_exit);
MODULE_LICENSE("GPL");你看，结构很清晰。注册、回调、注销，三步走。我刚开始写Linux驱动时，总搞混__init和__exit的用法。其实说白了，__init标记的代码在初始化完成后会被释放，节省内存。
Linux平台驱动框架
平台驱动（Platform Driver）是Linux中用于管理那些不依赖总线（如PCI、USB）的设备的框架。比如嵌入式系统中的GPIO、I2C控制器、SPI控制器等。它们通常直接挂在CPU的内存总线上。
平台驱动的核心是platform_driver结构体和platform_device结构体。驱动和设备通过名称匹配。
平台驱动的关键点：
- 驱动注册：
platform_driver_register() - 设备注册：
platform_device_register() - 匹配机制：通过
driver.name和device.name匹配 - 设备树（Device Tree）在现代内核中更常用
我记得有一次做嵌入式项目，需要写一个GPIO按键驱动。用平台驱动框架，只需要在设备树中定义好节点，驱动里通过of_property_read_u32()读取属性，非常方便。比起直接硬编码地址，这种方式可维护性高太多了。
避坑指南：我曾经在设备树中写错了reg属性，导致驱动probe函数一直不调用。排查了半天才发现是地址偏移量算错了。所以，写设备树时一定要仔细核对硬件手册。
总结一下
今天聊了四种驱动框架：
- WDM：Windows的老框架，IRP处理是核心
- WDF（KMDF/UMDF）：微软的现代方案，KMDF高性能，UMDF安全
- Linux字符设备：最基础的Linux驱动，file_operations是灵魂
- Linux平台驱动：适合嵌入式设备，设备树是趋势
每种框架都有它的适用场景。我个人觉得，没有最好的框架，只有最合适的。选框架时，要考虑性能要求、调试难度、团队经验等因素。嗯，今天就到这里，希望这些经验对你有帮助。