Upper and lower modules in the Windows Device Driver framework

Upper and lower modules in the Windows Device Driver framework

 

In the device driver framework of windows, the lower-layer module provides a data structure pointer to the upper-layer module. However, upper-layer modules do not directly obtain specific function pointers from this data structure, and do not directly use these function pointers to call functions in lower-layer modules; instead, some functions provided by the kernel issue the "I/O Request package", that is, IRP, which indirectly calls the functions provided by the lower-layer module and requires it to perform some operation. This is like placing an order on the kernel, which tells the kernel which lower-level module should perform the operation. On the other hand, for device drivers that have been built in the form of "stack", the upper-layer module usually does not have the problem of "Finding" the lower-layer module during operation, you don't even have to know what modules or devices are at the next layer. The modules have been fixed when they are stacked. At this time, the pointer of the lower-layer module obtained by the upper-layer module depends on the loading order of each module in the same stack, and actually depends on the system configuration, the related configuration information comes from the relevant. INF file, which is stored in the centralized database registry. In this way, it provides more flexibility to change the structure of the driver stack of a specific device through system configuration, mainly reflected in:
It is easier to achieve "redirection" at the bottom layer of the stack, that is, to graft the upper layer module to different lower layer modules;
It is easier to insert a "filter module" represented by "Fido" in the stack ".
Finally, the device driver module is not running in a vacuum environment and requires Kernel support. The kernel needs to build a runtime environment for it. The main body of this environment is the kernel export function, in addition, there are some global variables and data structures. This is the function and variable defined in the device driver development kit DDK of Windows (more accurately, "Declaration.
Things are developing, and the device-driven framework of windows is not like this at the beginning, not always. What we mentioned above is the necessary elements for implementing "plug-and-play", mainly the dynamic loading of modules and the formation of module stacks. With these elements, the driver of a layered device, including plug and play, can be implemented, but of course there are some additional requirements. Since Windows 98 and Windows 2000, Microsoft defined a new device driver framework, known as WDM, which is the "Windows Driver Model )". WDM requires that the device driver module not only meets the requirements of PNP, but also provides two functions:
WMI support. WMI is short for "Windows Management Instrumentation. Similar to SNMP, WMI requires that each Windows host be able to provide various statuses and statistical information, including device drivers, as required by the manager. Where does this information come from? The device driver must be provided by the corresponding device driver module.
Support for power management. Some peripherals consume a lot of energy. If they are not used for a long period of time, there is no reason not to transfer them into a certain "power-saving mode ". Even peripherals with low energy consumption should be transferred to the power-saving mode when energy conservation becomes an environmental problem. This is one of the goals of power management. Therefore, Microsoft lists power management as one of the elements of WDM.
In short, "old-fashioned" Device Drivers (in Form) are not layered or stacked; if the form is layered and stacked, Microsoft's term is referred to as "PNP device drivers ". The WDM device driver is a PNP device driver that meets the above two additional conditions at least in form. Of course, the importance of WMI support and power management cannot be underestimated, but it is not the technical key for us to understand the Windows Device Driver framework. Therefore, the subsequent descriptions will focus on the composition and implementation of the Framework, ignore these two aspects. Because of this, we will call it "Windows Device Driver framework" instead of "WDM" to avoid confusion.