Windows Driver Foundation 简介

On This Page

	简介
	Windows Driver Foundation
	WDF 发布计划
	资源

简介

Microsoft Windows 操作系统支持数千种设备。已经发布了超过 30,000 种驱动程序；每天都会出现新的驱动程序。其中一些驱动程序是基于十多年前设计的模型。尽管这些模型代表着当时的最高水平，但是现在的设备和操作系统技术暴露出了这些过时设计的局限性。

Microsoft 正在采取措施简化 Windows 驱动程序的开发，提高驱动程序质量和系统可靠性。本文描述了当前支持的 Windows 驱动程序模型，总结了它们的局限性，并介绍了能够克服这些局限性的 Windows Driver Foundation。

早期 Windows 驱动程序模型

早期的驱动程序模型包括一般的 Windows Driver Model (WDM) 和许多针对普通设备类（如存储、网络和音频）的设备类特定驱动程序模型。WDM 提供了一套丰富的功能，包括异步 I/O、驱动程序分层、即插即用、电源管理和 Windows 管理规范 (WMI)。

设备类特定的驱动程序模型的结构通常由 Microsoft 编写的端口驱动程序和独立硬件供应商编写的微型端口驱动程序组成。端口驱动程序承担设备类所需的大部分工作，而微型端口驱动程序支持设备特定的功能。例如，Microsoft 提供的 SCSI 端口驱动程序处理 SCSI 设备的基本要求，所以供应商提供的 SCSI 微型端口驱动程序只需支持设备特定的功能。

随着 Windows 增加了对新设备类的支持，微型端口模型的数量也随之增加。目前，Windows 支持 10 余种微型端口模型。

早期的驱动程序模型的局限性

尽管 WDM 和设备类特定的驱动程序模型提供了编写强大的高性能驱动程序所需的功能，但软件和硬件也在不断演化，所以，这些模型现在已显得有些老化了。具体来讲，下面的局限性突显了新模型的必要性。

一般的 WDM 驱动模型层次较低，而且复杂

编写基本的驱动程序需要数千行代码，其中许多代码只能实现常用功能。例如，支持即插即用和电源管理需要至少 2000 行复杂的代码。

许多驱动程序开发人员发现电源管理、即插即用、同步和异步 I/O 的设备驱动程序接口 (DDI) 非常复杂而且难以使用。实现一个完整的即插即用和电源管理状态引擎涉及到对至少一百种状态的支持。支持多功能设备的驱动程序甚至更加复杂。

设备驱动程序接口不是专为它们当前的目的而设计的，也没有版本控制功能

当许多年前设计 DDI 时，Microsoft 没有预料到第三方驱动程序的开发。因此，DDI 被直接从操作系统内核中导出。它们只是为性能而设计的，而不是为了安全或易用性。在许多情况下，DDI 直接向驱动程序公开基本的操作系统数据结构，从而限制了 Microsoft 更改这些结构的能力并增加了驱动程序错误导致系统崩溃或中断的机会。

没有版本控制支持，不同版本 Windows 的驱动程序常常需要不同的二进制文件或者必须编写为只能使用最早版本中的可用功能。 这些局限性增加了测试时间和支持成本。

有太多的微型端口模型

Windows 目前支持 10 余种微型端口模型。微型端口模型最初旨在简化驱动程序开发，屏蔽一些操作系统需求并在设备特定环境中展示其他需求。尽管微型端口模型通常比一般 WDM 模型更简单，但是往往很难确定使用哪个模型和如何在每个模型中实现常用功能。要为两种不同的设备类型（例如 NDIS 和存储）编写程序，开发人员必须理解两种不同的微型端口模型。

微型端口模型还有其他缺陷：

早期的驱动程序模型要求大多数驱动程序在内核模式下运行

大多数使用 WDM 和微型端口驱动程序模型的驱动程序必须在内核模式下运行。内核模式驱动程序被视为操作系统的一部分，并且能访问系统的虚拟地址空间。因此，内核模式驱动程序中的错误可能导致系统崩溃。

但是，用户模式应用程序不能访问系统结构或系统的虚拟地址空间。因此，操作系统独立于用户模式驱动程序失败。

现在许多设备没有中断或严格的计时要求，也不需要直接访问硬件寄存器。这些设备的驱动程序应该能在用户模式下运行，在用户模式下的系统可靠性风险要低得多。

驱动程序模型的数量使得测试和验证技术难以有效开发和使用

使用新的静态分析工具，例如 PREfast 和静态驱动程序验证工具 (Static Driver Verifier，SDV)，可以显著地提高驱动程序质量。这些工具根据一组规则验证驱动程序代码。但是由于驱动程序模型之间的巨大差异，不同的模型需要不同的规则集。开发这些工具来支持现有的驱动程序模型会涉及到重复的工作。

新一代 Windows Driver Model 的设计目标

使驱动程序易于开发、测试和维护有助于硬件供应商提高产品质量、缩短开发时间和降低成本。为了实现这些成果，Microsoft 为新一代 Windows Driver Model 制定了一些关键设计目标。

驱动程序模型应该简单、灵活

简单、灵活的驱动程序模型有助于开发人员更加轻松、快速地开发健壮、可靠的驱动程序。该模型必须有足够针对复杂的驱动程序进行扩展，必须支持即插即用、电源管理、同步、WMI、驱动程序分层和异步 I/O。另外，新模型应该具有足够的灵活性，以适应未来的系统创新。

驱动程序模型应该独立于核心操作系统组件

驱动程序模型应该是一个独立的外部框架，能够使驱动程序开发人员与操作系统细节相互独立。该模型应该允许 Microsoft 更改操作系统而不会引起驱动程序不兼容，而且应该使驱动程序开发人员和硬件供应商与操作系统的每个新版本和更新中的增量式更改相互独立。

驱动程序模型应该支持版本控制和并行支持

驱动程序模型应该支持版本控制，从而单一驱动程序二进制文件可以在操作系统的任何版本上运行。另外，该模型应该提供并行支持，支持两个或更多驱动程序同时使用两个或更多的主要版本。版本控制和并行支持使驱动程序二进制文件在操作系统的不同版本之间保持兼容，从而简化测试和安装要求。

驱动程序模型应该保持一致

驱动程序模型应该在所有设备类中保持一致。基本的 DDI 集应该支持所有设备的驱动程序都必须支持的操作系统功能，例如即插即用、电源管理、同步、I/O 队列、访问注册表和支持直接内存访问 (DMA)。适合于所有设备类的新功能可以添加到基本 DDI 集中。

一致的模型可以确保为一种设备类编写驱动程序时获得的知识可用于其他设备类，从而缩短了驱动程序开发人员的学习曲线。

驱动程序模型应该可扩展

扩展应该提供一个或多个特定设备类所需的功能，但不是每一种设备类所需的功能。

扩展性标准化了每种设备类的通用功能，从而使驱动程序开发人员可以专注于特定设备的独特细节。

驱动程序模型应该允许在用户模式中编写许多驱动程序

网络设备（基于通用即插即用规范）和一些 USB 设备需要专用设备的第三方支持。这些设备的驱动程序应该在用户模式下运行。用户模式驱动程序为系统可靠性带来的风险比内核模式驱动程序要低得多。

驱动程序模型应该支持使用高级语言

如果能够使用高级的面向对象和类型安全语言来表示接口，那么定义描述和验证接口的规则就会更加容易。准确描述接口对创建基于规则的代码分析工具至关重要。

DDI 应该以易于验证和分析作为设计目的

DDI 应该足够简单和直观以推动验证和分析工具（例如 PREfast 和 SDV）的开发和使用。

驱动程序模型应该允许驱动程序隔离 (driver isolation) 的未来开发

驱动程序模型应该允许驱动程序隔离的开发，以使驱动程序能够在受保护的环境下运行。当驱动程序这种受保护环境下运行时，操作系统可以从驱动程序错误中恢复，而不会导致故障。

Top of page

Windows Driver Foundation

Windows Driver Foundation (WDF) 是 Microsoft 实现这些设计目标的策略。WDF 是一个驱动程序概念模型，它包括以下组件：

WDF 提供了一个面向对象、事件驱动的模型，其中：

概念模型使驱动程序开发人员能够快速编写简单的驱动程序，并通过添加功能来逐步增加驱动程序的复杂性。WDF 被设计为使驱动程序开发人员能够专注于硬件和软件，而不是操作系统。

为了让驱动程序更易调试和维护，该框架包含了对 Windows 验证和事件跟踪的内置支持。调试和零售版本中都可以启用验证和跟踪功能。

Microsoft 将继续支持现有的驱动程序和微型端口模型，例如 WDM 和 NDIS。对于新的设备类，Microsoft 计划在 Windows Vista 中使用 WDF。

内核模式驱动程序框架

内核模式驱动程序框架 (KMDF) 实现内核模式驱动程序所需的基本功能，包括对即插即用、电源管理、I/O 队列、DMA、WMI 和同步的完全支持，以及对主流总线（例如 USB 和 IEEE 1394）的特定支持。另外，它能以一种适合于特定设备类的方式进行扩展，以支持特定设备类的功能和要求。KMDF 发行版包含适用于各种设备的大量示例驱动程序。

内核模式驱动程序框架不是操作系统内核的一部分。相反，它是一个独立的运行时库，支持版本控制和并行使用。

使用内核模式驱动程序框架编写支持多功能设备的总线驱动程序比使用当前的 WDM 模型要简单得多。驱动程序会列举出其子设备并列出每个子设备的属性。此框架处理所有其他的常用要求，例如设置设备对象、将 I/O 请求包 (IRP) 定向到子设备驱动程序等等。

内核模式驱动程序框架中的接口是为在未来提供驱动程序隔离而设计的。在驱动程序隔离下，内核模式驱动程序在受保护的环境下运行。如果驱动程序发生故障，系统将清除驱动程序分配的任何资源，并在不会引起系统崩溃或中断的情形下恢复。实现驱动程序隔离需要设计良好的接口，能够在受保护的环境下稳定地封送和验证。

用户模式驱动程序框架

用户模式驱动程序框架 (UMDF) 是一种通用的驱动程序平台，能够实现一部分内核模式框架功能，包括对电源管理、即插即用和异步 I/O 的支持。使用 UMDF，开发人员可以为基于协议或串行总线的设备创建驱动程序。这类驱动程序是标准的即插即用驱动程序，系统对它们进行查找和安装，就像内核模式即插即用驱动程序一样。

用户模式提供了比内核模式更加简单的操作环境。用户模式驱动程序只能访问自己的地址空间，不能访问系统地址空间；并且它们使用 Win32 API，而不是调用内核模式函数。因此，用户模式驱动程序能够提供更高的系统稳定性和安全性。然而，用户模式驱动程序具有一些局限性。它们不能直接操作硬件，因此不能执行 DMA 或使用中断。另外，它们不能拥有内核模式客户端或极其严格的计时要求。

驱动程序验证工具

两个基于规则的静态分析工具（PREfast 和 SDV）都支持用户模式框架和内核模式框架。这些工具也适用于非框架驱动程序，所以它们可以用于对现有驱动程序进行故障诊断。

PREfast 指示违反规则的地方和驱动程序必须遵循的约定。它每次将一组规则应用到一个函数并验证函数遵从范围内的代码，在函数级别上分析驱动程序的代码路径。 例如，如果函数 A 获得一个自旋锁并试图调用函数 Z，而函数 Z 必须在 PASSIVE_LEVEL 上调用，PREfast 将会标记这个错误，因为自旋锁的获取将 IRQL 提升到了 DISPATCH_LEVEL。但是，如果函数 A 获得了自旋锁，然后调用函数 M，而函数 M 可以在 DISPATCH_LEVEL 上合法调用，函数 M 然后尝试调用函数 Z，PREfast 就不能检测到此错误。

SDV 是一种基于规则的工具，它拥有关于 Windows 内部机制和驱动程序如何使用操作系统接口的内部知识。它通过驱动程序模拟操作系统的路径，例如，在调用驱动程序的AddDevice例程之前调用DriverEntry例程。当 SDV 发现错误时，它会显示从驱动程序代码到该错误的路径。SDV 可以发现 PREfast 不能发现的一些错误，例如前一段中描述的 IRQL 错误。由于会 SDV 根据用户选择的规则集探索驱动程序中所有的源代码路径，所以其运行时间和资源要求取决于驱动程序的大小和规则集的复杂性。较小的驱动程序的运行时间通常为 10-30 分钟。对于较大的驱动程序，验证许多复杂规则可能要花费好几个小时。

此外，WDF 包含一个内置的验证程序功能。此功能的工作方式与驱动程序验证工具 (Driver Verifier) 一样：它在注册表中设置一个标志，该标志用于启动驱动程序验证。

Top of page

WDF 发布计划

KMDF 和 UMDF 都能在 Windows Driver Foundation 网站上获得，该网站已在资源中列出。

Top of page

资源

Top of page