文件系统驱动编程基础篇之二——标准模型.doc

文件系统驱动编程基础篇之二——标准模型、基本例程、结构与函数 一、前略 本系列文章为业余编程爱好者而写，仅仅作为初学者的一个借鉴，真正的精华存在于参考资料*中。知识的积累将经历从薄到厚，再从厚到薄的反复过程，为了打下牢固的基础，请读者务必在阅读本文的基础上花费必要的时间完成参考资料。 笔者的实践环境为： 硬件：P35 Motherboard ICH9 chip，Pentium Dual Cpu E2160 1.8g， DDR2 1g 软件：Windows XP2、VS 2005、Visual AssistX、DriverStudio 3.2、MICROSOFT.WINDOWS.SERVER.V2003.IFS.DDK、Windbg 6.8.0004.0，请安装好用于调试的xp虚拟机并配置好调试环境。 参考资料*： 1．《Programming the Microsoft Windows driver model》第一版（当前阶段主要阅读资料，阅读第二至第五章） 2．《Kernel Debugging with WinDbg》 阅读基础：掌握c语言，会使用Msdn和WinDbg文档。 本章目的：了解驱动程序的标准模型，认识基本例程和初步了解常用结构与函数。 二、标准模型 WDM采用了结构化的编程方式，执行效率很高，但编写效率较低，这也是DriverStudio得以发展的重要原因。正如掌握了COM原理，使用ATL才能掌握精髓的道理一样，读者需要忍受记忆大量基础知识的“痛苦”，暂时放弃编写驱动程序的捷径。 下面的某些图示稍显陈旧，不过已经足以说明问题了。 尽管驱动程序分为多个种类（图1-4），但它们包含的基本内容（图1-5）是一致的。每个驱动程序都从初始化程序DriverEntry进入，通过某个派遣例程DispatchXXX派发特定命令（我们不妨称之为IRP），这些IRP有可能在派遣例程里就得到了解决，也有可能交给驱动程序的其他部分解决。如果驱动程序A本身不能处理这个IRP命令，它就需要将IRP传递到更下层的驱动B，由它们来处理，此时驱动程序A可能因为等待IRP完成而处于睡眠状态，或继续处理新的IRP，直到下层驱动B通知（或通过某种机制唤醒并通知）A该IRP已经处理完毕了，此时A就将处理的结果（我们称之为NTSTATUS）返回原来派发这个IRP的发起人。这就是驱动程序处理IRP的一个简化过程。 我们提到了驱动程序是分层的这个概念，那么如何理解分层的概念呢？请看图示： 引用资料1的原话：WDM模型使用了如图2-1的层次结构。图中左边是一个设备对象堆栈。设备对象是系统为帮助软件管理硬件而创建的数据结构。一个物理硬件可以有多个这样的数据结构。处于堆栈最底层的设备对象称为物理设备对象(physical device object)，或简称为PDO。在设备对象堆栈的中间某处有一个对象称为功能设备对象(functional device object)，或简称FDO。在FDO的上面和下面还会有一些过滤器设备对象(filter device object)。位于FDO上面的过滤器设备对象称为上层过滤器，位于FDO下面(但仍在PDO之上)的过滤器设备对象称为下层过滤器。_DriverEntry@8和DriverEntry。我们还习惯以IN，OUT宏显式说明函数的参数是输入或输出参数。 DriverEntry里常见的几个例程由红字标出，包括添加（硬件、虚拟）设备函数AddDevice、驱动卸载函数DriverUnload、StartIo函数以及放置于MajorFunction数组里的派遣函数。DriverEntry还申请了分页池以保存注册表中的服务键，但作为文件系统驱动的DriverEntry，一般还会声明快速IO派遣函数，这组派遣函数没有出现在示例中。 extern C NTSTATUS DriverEntry(IN PDRIVER_OBJECT DriverObject, IN PUNICODE_STRING RegistryPath) { DriverObject-DriverUnload = DriverUnload; --1 DriverObject-DriverExtension-AddDevice = AddDevice; DriverObject-DriverStartIo = StartIo; DriverObject-MajorFunction[IRP_MJ_PNP] = DispatchPnp; --2 DriverObject-MajorFunction[IRP_MJ_POWER] = DispatchPower; DriverObject-MajorFunction[IRP_MJ