Device Driver stacking for Windows Disks

Device Driver stack of a disk

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

As you can see in the previous sections, device drivers are often divided into two layers: Device Drivers and port drivers. For example, the mouse is a device type, and there are PS/2 mouse, serial mouse, and USB-based hid mouse, therefore, the mouse driver is divided into one type of device driver and three types of port device driver. The port driver of the PS/2 mouse is directly related to the hardware. However, the port driver may not directly drive the hardware, but only operate on the Virtual Hardware. This is the port driver of the hid mouse, because it is still separated from the actual hardware by the USB Bus layer, so you need to stack the driver of the hid port device on the USB bus driver, the USB driver is a USB driver and a port driver. As for the relationship between the driver of a class device and the driver of a port device, it can be either one-to-one or one-to-many.
There are three benefits for the division of device drivers and port drivers. On the one hand, similar to a mouse driver, you can extract public parts from different types of mouse drivers to avoid repetitive work during mouse driver development. This type of repetitive work is not only a waste, but also prone to errors and incompatibility. On the other hand, even if a device is not actually a "class", it is also beneficial to divide a device driver that can be a "whole-block" into two parts based on its logic and mechanism, this can improve software modularization and diversify the sources of these modules. In addition, the Division of drivers between devices and ports, as well as the standardization of the two in the interface form, also makes it possible to insert a "filter" module between the two as needed.
Therefore, Division of drive types and port drivers is an important concept and an important technology.
However, as far as disk drivers are concerned, the separation of class drivers and port drivers is still inadequate, because disks are logically and physically divided, and logical disks are likely to be partitions on physical disks, it may not actually be a disk. Therefore, under such conditions, the class driver will be further divided into two layers to become the upper and lower device objects. The above is called the functional device object) "fdo, the following is called" physical device drive (physical device object) ", that is, PDO. However, PDO is not necessarily a device object that deals directly with physical devices, but (up) represents a device object of a certain physical device, "representing" not necessarily "directly ". Sometimes, fdo and PdO are actually just "Up and down" points. Can the port device driver be further decomposed?
For the same device, the hardware interfaces from different manufacturers are also somewhat different. However, such differences are only partial and a small amount, which are generally concentrated at the underlying layer and directly related to the hardware, it is a little farther away from the specific hardware interfaces. Take a disk as an example. First, block storage devices form a category, which includes disks, tapes, and CDs, as well as USB disks and ramdisks. Disks are logically and physically divided. A physical disk can be divided into several partitions, and each partition is a logical disk. Then, physical disks are divided into IDE disks and SCSI disks. Finally, even if they are the same as IDE disks, the products of different manufacturers may be somewhat different and special, for example, the register of the IDE interface can be expressed in the I/o address space that can only be accessed through the In or out commands, or in the memory address space accessed through the mov command; some manufacturers also provide IDE disk arrays, and some may have special operation requirements. If each disk manufacturer is required to provide a full set of drivers, that is, the entire disk driver stack, then of course it is unrealistic. Even if you only need to provide the entire port driver, it will lead to many repeated development, and also put forward higher requirements for disk manufacturers, increasing the burden. However, if you can extract the public parts into a shared module, the disk manufacturer can only use the driver that is closely related to specific products, then the burden on the disk manufacturer can be minimized. This is the origin of the miniport driver. Mini has both the meaning of "small" and "minimalized. The extracted public part is still called the port driver, which is essentially part of the operating system kernel, so it is generally provided by Microsoft. The word "miniport" can be literally called "small port" or "minimum port", but it is not appropriate because it does not reflect the nature of this driver module; I think it may be okay to call it a "peripheral port", because miniport is directly dealing with hardware at the underlying layer.
Let's look at the interface between the upper and lower-level device objects. In the "class drive + Port Drive" model, the interface between the two is a conventional interface consisting of IRP and iocalldriver. Of course, the data or data structure carried on the IRP depends on the specific situation, which requires a protocol between the two modules. However, if the class drivers are divided into two layers: fdo and PDO, the interaction between the two layers is generally much more complex and close than that between the class drivers and the port drivers. At this time, the interaction between the two layers depends on IRP and iocalldriver () the interface is not enough. To this end, there is often another interface between fdo and PDO, and a data structure should be submitted from the lower layer to the upper layer, use this data structure to register the function pointers and data related to the upper layer. But now there is another problem, because the loading of the lower-layer driver module should be before the upper-layer module. In this case, how can the lower-layer module register with the unmounted upper-layer module? Therefore, fdo has to be divided into another part, which needs to be loaded before the lower-layer module. It acts as an intermediary between PDO and fdo, so that the lower-layer module can be pre-registered during initialization. This part is of course a module that can be loaded independently, but it does not create its own device object because of its device object (if it is actually available) it is the device object of the class driver to which it belongs. It will not be created until it is loaded. If we divide the device driver module into "tangible" and "invisible" based on whether there are device objects, this is an invisible device driver module. In essence, the invisible driver module is equivalent to the system space DLL, which is essentially an extension of the kernel. In addition, when an application opens a device, it can only target (named) the device object. Therefore, an invisible driver module cannot be used as the open target of the application.
In fact, dividing an invisible module from the class drive is not just to solve the problem of bottom-layer module (PDO) Up-layer registration. There is also the issue of "extracting public factors. For example, a disk is a type of device, that is, a disk, but it also belongs to a larger category, that is, a block storage device, and a tape category is also a block storage device. The two obviously have some commonalities. If they are implemented separately, a part of the disk drivers and the tape drivers are bound to be the same. Since there is a common part, it is better to extract it. In fact, classpnp. sys is a public part extracted from the class drive of the Windows block storage device.
The similar principle applies to the port driver and the small port driver. The interface between the two Device objects retains the IRP + iocalldriver (), added an Extended Interface Based on "Registration" from the lower layer to the upper layer.
Therefore, Windows's model, featuring IRP and iocalldriver (), is concise, but cannot be implemented all the time. It cannot be competent for complicated devices. While registering a data structure from the lower layer to the upper layer to provide function pointers and data is exactly what Linux uses.
It can be understood that the device object Stack Based on IRP and iocalldriver () forms the skeleton of a specific device driver, reflecting the overall hierarchical relationship; however, some layers in the skeleton can be further divided into sub-layers. The interfaces between sub-layers do not fully follow the IRP + iocalldriver () model. However, the filter driver can only be inserted between the backbone layers in the stack.
Next we will introduce the stacking of SCSI disks (excluding optical disks) drivers, but we will focus on the composition of stacking and the relationship between classes, ports, and small port drivers, instead of focusing on specific operation details, many details vary with specific hardware. We assume that the SCSI disk is used, and the interface inserted on the computer bus is "adapter", which is the 1540b interface board of adaptec. DDK provides a small port driver for this interface board, but does not provide a SCSI port driver, so some of the following code is taken from DDK, but some are taken from reactos. At the class driver layer, DDK provides both the disk. sys code and the classpnp. sys code.
For SCSI disks, the driver module stack consists:
Disk. sys. This is a disk-like drive. It is divided into fdo and PdO sub-layers, which have their own device objects. The combination of the two maps logical disk operations to physical disk operations. As mentioned above, disks and tapes are equivalent to block storage devices. Therefore, some public code that can be stored in disk. sys is extracted and becomes classpnp. sys. DDK provides the source code of this module.
Classpnp. sys. This is an invisible module. It does not have its own device object, but serves as a function library. DDK provides the source code of this module.
Scsiport. sys. The port driver of the SCSI disk, which is an invisible module and does not have its own device object. DDK does not provide the source code of this module, but reactos has implemented this module.
Aha154x. sys. This is a small port driver for the adaptec 1540b interface board. DDK provides the source code of this module.
The combination of disk. sys and classpnp. sys is equivalent to a class drive module. What is it called after being divided into two modules? In the source code of DDK, the path of the former is src/storage/class/disk, which seems to be a class drive. However, since the latter is named classpnp. sys, it should be a class drive. However, these two features are obviously different. The former is tangible, and the device objects it creates are in the device object stack, while the latter is only an invisible function library, it can be seen that Microsoft does not have a clear definition of what kind of drivers are class drivers. However, we can see from the code below that if the classpnp. sys understands as a drive for Block devices, while. sys can also be used to understand the drive of the sub-class "disk.
Now we can read the code.