Component I/O management module of Windows Kernel management layer

Windows Device Driver framework

One of the components of the Windows Kernel management layer is the I/O management module, also known as the I/O subsystem. The objects and activities managed by the I/O management module run vertically through the management layer, core layer, and even the Hal layer. Therefore, subsystems also make sense. The main body of I/O management is what we call the device driver. Naturally, if we look at the driver of a device along the vertical direction, it is generally divided into several layers. A basic principle of the operating system is hierarchical virtualization. Even if all the drivers of a device are in the same source program file, as long as they are not particularly simple device drivers, its design will consciously or unconsciously reflect the principle of layered virtualization. Therefore, the driver software of a device often acts as a "stack" of several drivers )". The top layer of the stack is in the management layer, while the bottom layer is in the Hal layer. The higher the stack, the farther the hardware is from the specific device, the more abstract it is, and the more common it is with other devices; the closer it is to the hardware of a specific device, the more specific it is, the more personalized it is. However, the upper-layer and lower-layer modules do not necessarily have one-to-one relationships, but can be one-to-many relationships. Taking the file system as an example, the top layer of the stack (in general) is the file system, and the bottom layer is the carrier of the file system. However, this carrier can be a disk, a CD, or a USB flash disk ". If it is a disk, it can be a fixed hard disk connected to the IDE interface or a SCSI disk. Therefore, the system structure in the logic sense of device driving is actually an (inverted) tree structure. A stack is actually a path from the root node to a specific leaf node.
On the other hand, the device driver is also the most important part of the kernel that needs to be dynamically expanded. This is because it is often difficult to know exactly which devices are needed when compiling and generating the system kernel. Obviously, the best way is to build a stack of various device drivers into a program module that can be dynamically installed, just like dynamic DLL loading in user space. In Windows, the file extension. sys is such a Dynamically Loaded kernel module. Note that the word "module" has different meanings in different contexts. When we talk about the I/O management module in the kernel management layer, it refers to a logically relatively self-contained part, which may be called a "plate. When talking about the. SYS module, it refers to an executable image that can be dynamically loaded. This Dynamically Loaded executable image can be large or small. In fact, win32k. sys is such a module. Of course, other modules are not that big. In practice, drivers of a specific device are stacked into one based on specific needs. SYS module; or implement one or more layers in a stack into one. SYS module, which is used by one or more. the SYS module provides a driver stack for this device.
Therefore, there are two problems with Device Drivers: one is the layering problem and the other is the dynamic loading problem.
However, there are concepts and forms of program hierarchy. Conceptual Hierarchy is only a matter of programmer programming methods. Of course, it also reflects the skill and level of programmers. formal hierarchy, the model and framework set by the system for the development of device drivers. On the one hand, developers are required to develop device drivers based on specific models that reflect program layering, on the other hand, it also provides infrastructure support for device drivers that conform to this model. For example, a rack is like a rack. On the one hand, it requires that all modules to be inserted into the rack comply with certain rules in terms of shape and size. On the other hand, as long as you comply with such rules, the Rack provides you with power supply, ventilation, inter-module communication, and other infrastructure.
For the device driver module of windows, this framework defines:
The form in which the device driver module provides relevant operations (embodied as a data structure containing several function pointers) and the scope of these operations (Open, close, read, write, etc ).
How to start specific operations provided by the device driver module (assembling parameters such as the "operation code" in a standard format data structure "I/O Request package" that is, IRP, using this data structure as a formal call parameter, the device driver framework provides iocalldriver () to call the corresponding function pointer provided by the device driver module ).
If needed, how can a device driver module start operations on its lower-layer modules (still through iocalldriver () and upload the "I/O Request package" to the next layer ).
Which functions of the kernel can be called from the device driver and which variables of the kernel can be accessed (DDK of Windows stipulates this ).
A fixed model can be defined for the interface of the device driver module because the service provided by the device driver module has a fixed range and belongs to a fixed set, it can be opened, closed, read, or written. In contrast, the user space DLL is not as standard as the device driver module, because in general, the DLL provides a wide variety of services, not limited to a fixed set, therefore, they cannot be unified into a set of fixed function sets.

 

This article is excerpted from "Windows Kernel scenario analysis-using open-source reactos"