2014文件系统驱动编程基础之.docVIP

文件系统驱动编程基础篇之2——标准模型 关键字：文件系统驱动编程,标准模型,基本例程,结构与函数 作者：wskjuf 更新：2008-10-06 22:08:47 浏览：7293 文件系统驱动编程基础篇之二——标准模型、基本例程、结构与函数 一、前略 二、标准模型 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之上)的过滤器设备对象称为下层过滤器。由某个家伙（可能是用户模式下的应用程序，也可能是系统内核组件）发起的IRP从上层过滤器驱动程序一直顺流而下，传递到总线驱动程序处理后，再逐级返回上层，最终发起人得到处理的结果。一般情况下，IRP也许不需要传递到总线驱动程序就被处理掉了，但如果大家都不认识这个IRP，他们就只好逐级下传了，如果此时有个搞破坏的驱动程序混了进来，拦截了这个IRP，轻则丢失用户信息、重启、死机，重则造成系统区的数据混乱，你除了重新安装操作系统再无任何事情可做。由此可见，我们不要求驱动程序“有理想”，但必须“有纪律”，每个驱动程序都必须严格按照规范书写代码，这要求编程人员具备较高的素质。下面我们来了解驱动编程里最基本的标准模型，这个模型不能解决所有的编程需求，根据需要，它将存在各种变化。我们来看看这个驱动编程里的“基本定式”： IO管理器，大家应该理解为该IRP的发起人，可能是张三，也可能是李四，而不是某个固定的组件。这个模型表明了单个驱动程序里各部件的合作与分工，注意它是个循环不断的过程，它的发起人与最终接受人是相同的，所谓“从哪里来，就回哪里去”。如果我们的编程不涉及真正的硬件，StartIo例程、中断服务例程ISR、DPC例程均可能不存在。各部件的具体功能请参看资料1的第五章。 三、基本例程、常用数据结构与函数 为正确理解各类例程的具体功能，需要弄清涉及的众多内核函数、数据结构，读者应以本文和资料1为索引，认真的阅读Msdn上的相关内容。我们的代码将从入口函数DriverEntry处开始执行，一般情况下，不要将它改名，否则需要修改DDK里的Build脚本。驱动函数定义一般采用__stdcall约定，这个约定，在vs和bcb里的实际行为是不同的。如DriverEntry，两种编译器编译后的库中名字（即外部名字）分别是_DriverEntry@8和DriverEntry。我们还习惯以IN，OUT宏显式说明函数的参数是输入或输出参数。DriverEntry里常见的几个例程由红字标出，包括添加（硬件、虚拟）设备函数AddDevice、驱动卸载函数DriverUnload、StartIo函数以及放置于MajorFunction数组里的派遣函数。DriverEntry还申请了分页池以保存注册表中的服务键，但作为文件系统驱动的DriverEntry，一般还会声明快速IO派遣函数，这组派遣函数没有出现在示例中。 示例同时引用了多种数据结构，它们的详细注释可参看资料1第二章的第一小