USB接口通信驱动的设计与开发

引言WDM 是“Windows 驱动程序模型 ”的简称，即“Windows Driver Model”。实际上它是一系列集成在操作系统之中的常规系统服务集，用于简化硬件驱动程序的编写，并保证它们在 Windows 98/Me/2000 中的二进制兼容，WDM（Windows Driver Model）模型是从 WinNT3.51 和 WinNT4 的内核模式设备驱动程序发展而来的。WDM 主要的变化是增加了对即插即用、电源管理、Windows Management Interface(WMI)、设备接口的支持。WDM 模型的主要目标，是实现能够跨平台使用、更安全、更灵活、编制更简单的 Windows 设备驱动程序。WDM 采用了“ 基于对象”的技术，建立了一个分层的驱动程序结构。WDM 首先在 Windows98 中实现，在 Windows2000 中得到了进一步的完善，并在后续开发的 Windows 操作系统中都将存在，比如 Windows Me 和 Windows XP。微软在通过 WDM 模型的引入，希望减轻设备驱动程序的开发难度和周期，逐渐规范设备驱动程序的开发，应该说，WDM 将成为以后设备驱动程序的主流。USB 技术的全称是通用串行总线，是英文 Universal Serial Bus 的缩写。它是一种应用在 PC 领域的新型接口技术，虽然 USB2.0 已经被广泛应用，但是初始的 Windows 2000 是支持 USB1.0 协议的，如果希望支持 USB2.0 协议，需要在微软网站上下载升级包。实际上，对于键盘或者鼠标来说，传输的速度非常小，使用 USB1.0 或者是USB2.0 的区别并不大。闪存盘之类的存储设备，则需要重视传输速度。USB1.0 版本主要应用在鼠标，键盘等 HID 设备上，这就是本驱动程序中引用的头文件版本是USB1.0 的原因。本毕业设计的目的是希望对 Windows 2000 操作系统体系结构和驱动程序开发以及调试等方面的问题有一个比较深入的了解，对 USB 协议和 USB 体系有做一个比较深入的了解。并开发出一个 USB 键盘驱动。这个 USB 键盘驱动程序应当可以替代系统原有的键盘驱动程序，并可以正常工作。本论文设计的驱动程序在 Windows 2000 下运行，开发环境为 VC6.0 和DDK2000。1 WDM 驱动程序模型概述驱动程序在任何操作系统下都和系统内核有着密切的关系。设备驱动程序是一个包含了许多操作系统可调用例程的容器，这句 Walter Oney 曾说过的话，抽象的描述了设备驱动程序的本质。1.1 Windows 2000 概述图 11 中概括了 Windows 200 系统中的组件，Windows 2000 操作系统是由不同层次的模块共同组成的。该图着重描述了驱动程序开发者所关心的特征。工作在Windows 2000 操作系统平台上的软件要么执行在用户模式中，要么执行在内核模式中。当用户模式程序需要读取设备数据时，就调用 Win32 API 函数，如 ReadFile. Win32 子系统模块通过调用平台相关的系统服务接口实现 API，而平台相关的系统服务将调用内核模式支持例程。在 ReadFile 调用中，调用首先到达系统 DLL(NTDLL.DLL)中的一个入口点，NtReadFile 函数。然后这个用户模式的 NtReadFile 函数接着调用系统服务接口，最后由系统服务接口调用内核模式中的服务例程，该例程同样名为NtReadFile。应用程序Win32 子系统设备驱动硬件抽象层硬件IO 管理器用户模式内核模式Win32API 调用系统服务接口传递 IRP 给驱动程序派遣函数HAL 调用平台相关操作图 11 Windows 组件模型系统中还有许多与 NtReadFile 相似的服务例程;它们同样运行在内核模式中，为应用程序请求提供服务，并以某种方式与设备交互。这些服务例程首先检查从用户态传递给它们的参数以保护系统安全或防止用户态程序非法存取数据，然后创建一个称为“I/0 请求包(IRP)” 的数据结构，并把这个数据结构送到某个驱动程序的入口点。驱动程序完成一个 I/0 操作后，通过调用一个特殊的内核模式服务例程来完成该IRP。完成操作是处理 IRP 的最后动作，它使等待的应用程序恢复运行。1.2 Windows 2000 中的驱动程序类型虚拟设备驱动程序（VDD ）内核模式驱动程序文件系统驱动程序遗留设备驱动程序PnP驱动程序显示驱动程序WDM驱动程序类驱动程序微型(mini)驱动程序图 12 Windows 2000 中的设备驱动程序种类Windows 2000 系统可以使用多种驱动程序，图 1-2 显示了其中几种。虚拟设备驱动程序(VDD)可以使 DOS 应用程序访问 x86 平台上的硬件。VDD 通过屏蔽 I/O 权限掩码来捕获端口存取操作，它基本上是模拟硬件操作，这对于那些直接对裸机硬件编程的应用程序特别有用。尽管这种驱动程序在 Windows 98 和 Windows 2000 中共享一个名称并且有相同的功能，但实际上它们的工作方式完全不同。我们用VDD 缩写代表这种驱动程序，用 VxD 缩写代表 Windows 98 中的虚拟设备驱动程序以示区别。内核模式驱动程序的分类包含许多子类。PnP 驱动程序就是一种遵循 Windows 2000即插即用协议的内核模式驱动程序。WDM 驱动程序是一种 PnP 驱动程序，它同时还遵循电源管理协议，并能在Windows98 和 Windows 2000 间实现源代码级兼容。WDM 驱动程序还细分为类驱动程序(classdriver)和微型驱动程序 (minidriver)，类驱动程序管理属于己定义类的设备，微型驱动程序向类驱动程序提供厂商专有的支持。显示驱动程序是用于显示和打印设备的内核模式驱动程序。文件系统驱动程序在本地硬盘或网络上实现标准 PC 文件系统模型(包括多层次目录结构和命名文件概念)。遗留设备驱动程序也是一种内核模式驱动程序，它直接控制一个硬件设备而不用其它驱动程序帮助。这种驱动程序主要包括 Windows NT 早期版本的驱动程序，它们可以不做修改地运行在 Windows 2000 中。1.3 WDM 驱动程序类型WDM（ Windows Driver Model）模型是从 WinNT3.51 和 WinNT4 的内核模式设备驱动程序发展而来的。WDM 主要的变化是增加了对即插即用、电源管理、Windows Management Interface(WMI)、设备接口的支持。WDM 模型的主要目标，是实现能够跨平台使用、更安全、更灵活、编制更简单的 Windows 设备驱动程序。WDM 采用了“ 基于对象”的技术，建立了一个分层的驱动程序结构。 WDM 首先在 Windows98 中实现，在 Windows2000 中得到了进一步的完善，并在后续开发的 Windows 操作系统中都将存在，比如 Windows Me 和 Windows XP。微软在通过 WDM 模型的引入，希望减轻设备驱动程序的开发难度和周期，逐渐规范设备驱动程序的开发，应该说，WDM 将成为以后设备驱动程序的主流。在 WDM 模型中，每个硬件设备至少有两个驱动程序：一个功能驱动程序（function driver）和一个总线驱动程序（bus driver） 。一个设备还可能有过滤驱动程序（filter driver） ，用来变更标准设备驱动程序的行为。这些服务于同一个设备的驱动程序组成了一个链表，称为设备栈。详细的描述见图 1-3。可选的上层过滤驱动程序功能驱动程序可选的底层过滤驱动程序可选的总线过滤驱动程序总线驱动程序设备驱动程序总线驱动程序图 1-3 驱动程序的种类总线驱动程序总线驱动程序为实际的 IO 总线服务，比如 IEEE 1394。在 WDM 的定义中，一个总线是这样的设备，它用来连接其他的物理的、逻辑的、虚拟的设备。总线包括传统的总线 SCSI 和 PCI，也包括并口、串口、以及 i8042 端口。微软已经为 Windows 操作系统提供了总线驱动程序。总线驱动程序已经包含在操作系统里了，用户不必安装。一个总线驱动程序负责以下的工作：枚举总线上的设备；向操作系统报告总线上的动态事件；响应即插即用和电源管理的 IO 请求；提供总线的多路存取（对于一些总线） ；管理总线上的设备；功能驱动程序功能驱动程序是物理设备的主要驱动程序，它实现设备的具体功能，一般由设备的生产商来编写。功能驱动程序的主要功能是：提供对设备的操作接口；操作对设备的读写；管理设备的电源策略；过滤驱动程序过滤驱动程序是一个可选项，当一个用户需要改变或新添一些功能到一个设备、一类设备或一种总线时，就可以编写一个过滤驱动程序。在设备栈里，过滤驱动程序安装在一个或几个设备驱动程序的上面或下面。过滤驱动程序拦截对具体设备、类设备、总线的请求，做相应的处理，以改变设备的行为或添加新的功能。但过滤驱动程序只处理那些它所关心的 IO 请求，对于其他的请求可以交给其他的驱动程序来处理，这样可以非常灵活改变设备的行为，至少用户会这样看。比如：一个 USB 键盘的上层过滤驱动程序可以强制执行附加的安全检查。一个鼠标的低层过滤驱动程序，通过对鼠标移动的数据做非线性的转换，可以得到一个有加速效果的鼠标轨迹。功能驱动程序的组成功能驱动程序由类驱动程序和微型驱动程序（Minidriver）组成。类驱动程序实现了某一类设备的常用操作，由微软提供，驱动程序的开发者可以只编写非常小的微型驱动程序，去处理具体设备特殊的操作，而对于其他大量的常规操作，可以调用该类的类驱动程序，这也是 WDM 驱动程序的优点之一。微软提供的类驱动程序处理常用的系统任务，比如，即插即用功能和电源管理。类驱动程序保证了操作系统在处理类似的任务时的一致性，从而提高了系统的稳定性。设备生产商提供微型驱动程序，以实现自己设备的特殊功能，同时调用合适的类驱动程序完成其他的通用工作。将大量的标准操作的代码通过各种类驱动程序来实现，并集成在操作系统中，这样的方式可以有效的减少具体设备的微型驱动程序的大小，也就减小了程序出错的可能。如果某一类设备存在着工业标准，微软就会提供一个该类设备的 WDM 类驱动程序。这个类驱动程序实现了该类设备所有必须的任务，但不实现任何具体设备所特有的东西。比如，微软提供的 HID（人工输入设备）类驱动程序的实现，是根据 USB HID 类规范 v.11 的规定，但并不实现任何一种具体设备的特殊功能，比如，USB 键盘、鼠标、游戏控制等等。本文所设计的驱动程序就是一个功能驱动程序,它是将 USB 驱动程序与微型驱动程序(Minidriver) 结合起来,驱动 USB 键盘的一个驱动程序.微软支持的 WDM 总线和类驱动程序图 1-4 微软支持的 WDM 总线和类驱动程序对于图 1-4,本文只描述其中的人工输入设备(HID) 和 USB 部分。因为这是在 USB键盘驱动程序设计中所涉及到的两个方面。USB 总线驱动程序枚举和控制低速的 USB总线。USB 客户驱动程序使用各种 IOCTL 通过 USB 类驱动程序访问它们的设备。人工输入设备（HID）类驱动程序管理多种总线（如 USB）间的数据与指令语法翻译。大多数时候，本类驱动控制由用户交互接口传来的数据，如键盘，鼠标和游戏杆等。1.4 驱动程序的分层结构FiDOFDOFiDOPDO上层过滤驱动程序功能驱动程序低层过滤驱动程序总线驱动程序IRP图 15 WDM 中设备对象和驱动程序的层次结构WDM 模型使用了如图 15 的层次结构。图中左边是一个设备对象堆栈。设备对象是系统为帮助软件管理硬件而创建的数据结构。一个物理硬件可以有多个这样的数据结构。处于堆栈最底层的设备对象称为物理设备对象(physical device object)，或简称为 PDO。在设备对象堆栈的中间某处有一个对象称为功能设备对象(functional device object)，或简称 FDO。在 FDO 的上面和下面还会有一些过滤器设备对象(filter device object)。位于 FDO 上面的过滤器设备对象称为上层过滤器，位于 FDO 下面(但仍在PDO 之上)的过滤器设备对象称为下层过滤器。操作系统中的即插即用管理器（PnP Manager）根据设备驱动程序的指令来建立这个数据对象堆栈。前面我们已经知道，总线驱动程序的作用之一是枚举总线上的设备，当总线驱动程序检测到一个设备时，PnP 管理器就马上建立一个 PDO。当建立好 PDO之后，PnP 管理器通过查找注册表来找到其他的过滤驱动程序和功能驱动程序。设备的安装程序负责建立这些注册表里的表项，驱动程序的安装，是根据 INF 文件中的指令进行的。注册表中的表项指明了各种驱动程序在数据对象堆栈中的位置，于是 PnP管理器开始装载最低层的过滤驱动程序，并调用该驱动程序的 AddDevice 函数。该函数在数据对象堆栈中建立一个 FiDO，同时也将前面建立的 PDO 和这个 FiDO 联系在一起。PnP 管理器反复的实现该过程，装载其他位置靠上的低层过滤驱动程序、功能驱动程序、上层过滤驱动程序，直到该堆栈完成。应用程序对设备的存取通过提交 IO 请求包（IRP）来进行。在操作系统中，对设备的存取过程是这样的：操作系统中的 IO 管理器接受 IO 请求（通常是由用户态的应用程序发出的） ，建立相应的 IRP 来描述它，将 IRP 发送给合适的驱动程序，然后跟踪执行过程，当操作完成后，将返回的状态通知请求的发起者。操作系统中的 IO管理器、即插即用管理器、电源管理器都使用 IRP 来与内核模式驱动程序、WDM 驱动程序进行通信，并且，各驱动程序之间的通信也是依靠 IRP。在 WDM 驱动程序中，IRP 首先从最上层进入，如图 15 里右手边的箭头，然后，依次往下传送。在每一层，驱动程序自行决定对 IRP 的处理。有时，一个驱动程序除了把继续 IRP 向下传递外，并不做任何事情。有时，一个驱动程序会完全接管 IRP，不再把它向下传递了。当然，一个驱动程序也可以处理 IRP 后，再把它继续向下传递。这取决于驱动程序的功能和 IRP 的含义。从这里，可以知道微软在 WDM 模型中使用分层的驱动程序结构的原因了，通过分层的方法，在处理对设备的 IO 请求时，利用添加合适的驱动程序层的方法，从而非常灵活的改变设备的行为，以实现不同设备的功能。1.5 IO 请求包（IRP）操作系统使用 I/0 请求包(IRP)数据结构与内核模式驱动程序通信。这个数据结构很重要，需要了解它的创建、发送、处理，以及最后的销毁。可以说，IO 请求包（IRP）才是 WDM 驱动程序结构的最重点，只有真正了解处理 IRP 的过程，才算是真正懂得了设备驱动的原理。1.5.1IRP 结构图 16 I/O 请求包数据结构MdlAddress(PMDL)域指向一个内存描述符表(MDL)，该表描述了一个与该请求关联的用户模式缓冲区。如果顶级设备对象的 Flags 域为 DO_DIRECT_IO，则 I/O 管理器为 IRP_MJ_READ 或 IRP_MJ_WRITE 请求创建这个 MDL。如果一个IRP_MJ_DEVICE_CONTROL 请求的控制代码指定 METHOD_IN_DIRECT 或METHOD_OUT_DIRECT 操作方式，则 I/O 管理器为该请求使用的输出缓冲区创建一个 MDL。MDL 本身用于描述用户模式虚拟缓冲区，但它同时也含有该缓冲区锁定内存页的物理地址。为了访问用户模式缓冲区，驱动程序必须做一点额外工作。Flags(ULONG)域包含一些对驱动程序只读的标志。但这些标志与 WDM 驱动程序无关。AssociatedIrp(union)域是一个三指针联合。其中，与 WDM 驱动程序相关的指针是AssociatedIrp.SystemBuffer。 SystemBuffer 指针指向一个数据缓冲区，该缓冲区位于内核模式的非分页内存中。对于 IRP_MJ_READ 和 IRP_MJ_WRITE 操作，如果顶级设备指定 DO_BUFFERED_IO 标志，则 I/O 管理器就创建这个数据缓冲区。对于IRP_MJ_DEVICE_CONTROL 操作，如果 I/O 控制功能代码指出需要缓冲区(见第九章)，则 I/O 管理器就创建这个数据缓冲区。I/O 管理器把用户模式程序发送给驱动程序的数据复制到这个缓冲区，这也是创建 IRP 过程的一部分。这些数据可以是与 WriteFile 调用有关的数据，或者是 DeviceIoControl 调用中所谓的输入数据。对于读请求，设备驱动程序把读出的数据填到这个缓冲区，然后 I/O 管理器再把缓冲区的内容复制到用户模式缓冲区。对于指定了 METHOD_BUFFERED 的 I/O 控制操作，驱动程序把所谓的输出数据放到这个缓冲区，然后 I/O 管理器再把数据复制到用户模式的输出缓冲区。IoStatus(IO_STATUS_BLOCK)是一个仅包含两个域的结构，驱动程序在最终完成请求时设置这个结构。IoStatus.Status 域将收到一个 NTSTATUS 代码，而IoStatus.Information 的类型为 ULONG_PTR，它将收到一个信息值，该信息值的确切含义要取决于具体的 IRP 类型和请求完成的状态。 Information 域的一个公认用法是用于保存数据传输操作，如 IRP_MJ_READ，的流量总计。某些 PnP 请求把这个域作为指向另外一个结构的指针，这个结构通常包含查询请求的结果。RequestorMode 将等于一个枚举常量 UserMode 或 KernelMode，指定原始 I/O 请求的来源。驱动程序有时需要查看这个值来决定是否要信任某些参数。PendingReturned(BOOLEAN)如果为 TRUE，则表明处理该 IRP 的最低级派遣例程返回了 STATUS_PENDING。完成例程通过参考该域来避免自己与派遣例程间的潜在竞争。Cancel(BOOLEAN)如果为 TRUE，则表明 IoCancelIrp 已被调用，该函数用于取消这个请求。如果为 FALSE，则表明没有调用 IoCancelIrp 函数。取消 IRP 是一个相对复杂的主题，我将在本章的最后详细描述它。CancelIrql(KIRQL)是一个 IRQL 值，表明那个专用的取消自旋锁是在这个 IRQL 上获取的。当你在取消例程中释放自旋锁时应参考这个域。CancelRoutine(PDRIVER_CANCEL)是驱动程序取消例程的地址。你应该使用IoSetCancelRoutine 函数设置这个域而不是直接修改该域。UserBuffer(PVOID) 对于 METHOD_NEITHER 方式的IRP_MJ_DEVICE_CONTROL 请求，该域包含输出缓冲区的用户模式虚拟地址。该域还用于保存读写请求缓冲区的用户模式虚拟地址，但指定了 DO_BUFFERED_IO 或DO_DIRECT_IO 标志的驱动程序，其读写例程通常不需要访问这个域。当处理一个METHOD_NEITHER 控制操作时，驱动程序能用这个地址创建自己的 MDL。Tail.Overlay 是 Tail 联合中的一种结构，它含有几个对 WDM 驱动程序有潜在用途的成员。由于篇幅有限，这里不再讨论。1.5.2IRP 处理的 “标准模型”（1）创建 IRPIRP 开始于某个实体调用 I/O 管理器函数创建它。在上图中，我使用术语 “I/O 管理器”来描述这个实体，尽管系统中确实有一个单独的系统部件用于创建 IRP。事实上，更精确地说，应该是某个实体创建了 IRP，并不是操作系统的某个例程创建了 IRP。例如，你的驱动程序有时会创建 IRP，而此时出现在图中第一个方框中的实体就应该是你的驱动程序。可以使用下面任何一种函数创建 IRP： IoBuildAsynchronousFsdRequest 创建异步 IRP(不需要等待其完成)。该函数和下一个函数仅适用于创建某些类型的 IRP。 IoBuildSynchronousFsdRequest 创建同步 IRP(需要等待其完成)。 IoBuildDeviceIoControlRequest 创建一个同步 IRP_MJ_DEVICE_CONTROL 或IRP_MJ_INTERNAL_DEVICE_CONTROL 请求。 IoAllocateIrp 创建上面三个函数不支持的其它种类的 IRP。 前两个函数中的 Fsd 表明这些函数专用于文件系统驱动程序(FSD)。虽然 FSD 是这两个函数的主要使用者，但其它驱动程序也可以调用这些函数。DDK 还公开了一个IoMakeAssociatedIrp 函数，该函数用于创建某些 IRP 的从属 IRP。WDM 驱动程序不应该使用这