Windows Driver Foundation 事实

“整个 PnP/电源管理接口太费解了，甚至很难向人讲明白。”

“两个词：电源管理。……还有比这更让人痛苦的吗？PnP 至少还容易理解……”

“电源管理极其复杂，有太多子状态。”

“启动一个错误很多的 DDK/知识库示例后，我最终获得了 IRP 取消权限。”

“每个驱动程序应该包含的样板代码 (boilerplate code) 太多了。”

“缺乏关于 PnP 与电源管理事件之间的同步问题的信息。”

“我认为 IRP 注销是唯一棘手的区域。”但是有了 WDM，电源管理和 PnP 就被“粘贴”到了接口端上。”

“如果某些功能无法生效，则很难诊断出错误的位置。”

“新开发人员面临着非常陡峭的学习曲线。”

“时间不可或缺 - 但是可靠性是最主要的因素。”

PnP (22%) - 需要超过 3000 行样板代码。
I/O 没有可用的同步支持。

Power (20%) - 处理所有电源状态非常复杂。
很难获得等待唤醒/选择性暂停权限。

IRP 取消 (17%) - I/O 取消逻辑涉及一些竞争条件，并且很难获得权限。

并发和竞争条件（尤其是 PnP/取消/I/O）。

50% 的驱动程序开发人员认为现有的 WDM 驱动程序模型很复杂。

70% 的驱动程序开发人员声称想要更新的模型。

70% 的驱动程序开发人员想要一个用户模式驱动程序框架。

内核模式框架和用户模式框架支持大多数设备要求。

静态工具（例如 SDV 和 PFD）能够自动发现 bug。

内置诊断和验证工具。

调试器扩展。

版本控制允许框架的多个版本同时存在。

处理 PnP 和 Power IRP 不再需要复杂的样板代码。

框架为 PnP 和 Power IRP 提供了默认处理和正确行为。

框架提供了最新的电源管理技术，内置了对运行时空闲和唤醒计算机的支持。

同步模型可以解决异步事件的并发问题 - 工作项、DPC、计时器、取消 I/O 请求。

使用 I/O 目标简化了驱动程序之间的通信。

不用担心 PnP IRP 与 I/O IRP 的同步或与 ISR 的 DPC 的同步。

队列与 PnP 和电源实现进行了同步。

三种不同模型可用于控制传送到驱动程序的请求的并发：顺序、并行和手动。

将请求的取消构建到了框架中。在大多数情况下，开发人员不必担心在其驱动程序中提供取消支持。

允许在 I/O 处理期间调用可选的 I/O 事件回调序列化。