Windows的设备驱动框架中的上层与下层模块

Windows的设备驱动框架中的上层与下层模块

 

     在Windows的设备驱动框架中，下层模块向上层模块提供一个数据结构指针。但是，上层模块并不直接从这个数据结构获取具体的函数指针，更不直接使用这 些函数指针调用下层模块中的函数；而是通过一些由内核提供的函数下达“I/O请求包”即IRP，间接地调用下层模块提供的函数，要求其执行某种操作。这就 好像是向内核下一个定单，定单中告诉内核要由哪一个下层模块执行何种操作。另一方面，对于建立了形式“堆叠”的设备驱动，上层模块在运行中通常也没有如何 “找到”下层模块的问题，甚至根本就不必知道其下一层是什么模块或什么设备，模块之间已在建立形式堆叠的时候固定连接好了。此时上层模块所获得的是哪一个 下层模块的指针，取决于同一个堆叠中各个模块的装载次序，实际上取决于系统的配置，而相关的配置信息则最终来自相关的.inf文件，这些信息保存在集中的 数据库“注册表（Registry）”中。这样就为通过系统配置改变具体设备驱动堆叠的结构提供了更大的灵活性，主要体现在：
    更容易在堆叠的下层实现“重定向”，即把上层模块嫁接到不同的下层模块上；
    更容易在堆叠内部插入以“过滤驱动对象（FiDO）”为代表的“过滤模块”。
最后，设备驱动模块不是在真空中运行，需要得到内核的支持，需要由内核为其构筑起一个运行环境，这个环境的主体就是内核导出函数，此外还有一些全局的变量和数据结构。这就是Windows的“设备驱动开发包”DDK中所定义（更准确地说是“声明”）的函数和变量。
    事物都是在发展的，Windows的设备驱动框架也不是一开始就这样，更不是永远这样。前面所讲的是为实现“即插即用”所必须要有的要素，主要就是模块的 动态装载以及模块堆叠的形成。有了这些要素，包括即插即用在内的分层设备驱动就可以实现了，但是当然还可以有一些附加的要求。从Windows 98和Windows 2000开始，微软定义了一种（在当时是）新的设备驱动框架，称为WDM即“Windows设备驱动模型（Windows Driver Model）”。WDM要求设备驱动模块除满足PnP的需要外，还必须提供两方面的功能支持：
    对于WMI的支持。WMI是“Windows管理手段（Windows Management Instrumentation）”的缩写。WMI与“简单网络管理规程”SNMP相似，要求每台Windows主机都能应“管理器（Manager）” 的要求提供包括设备驱动在内的各种状态和统计信息。这些信息从哪儿来呢？对于设备驱动，当然得要由相应的设备驱动模块提供。
    对于电源管理的支持。有些外设能耗不小，如果有一段较长的时间没有实际使用，就没有理由不将其转入某种“省电模式”。即使是能耗不大的外设，在节能成为一 个环保问题的今天，也应该在不用时使其转入省电模式。这就是电源管理要达到的目的之一。所以，微软把支持电源管理列为WDM的要素之一。
    总之，“老式”的设备驱动（在形式上）是不分层、不堆叠的；如果形式上分层并堆叠，在微软的术语中就称为“PnP设备驱动”。而WDM设备驱动，则是至少 在形式上满足了上述两项附加条件的PnP设备驱动。对WMI的支持和电源管理的重要性当然不容低估，但是对于我们理解Windows的设备驱动框架却并非 技术关键，所以后面的叙述将集中在框架的构成与实现，而忽略这两个方面。正因为这样，我们将称之为“Windows设备驱动框架”而不是“WDM”，以免 混淆。