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

    二、标准模型

    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的第五章。