Windows 2000/XP class/port/miniport driver model (http://webcrazy.yeah.net)

Detailed description of the Windows 2000/XP class/port/miniport driver model
WebSphere (http://webcrazy.yeah.net)

For software reuse, Microsoft Windows provides COM (Component Object Model) at the user layer, which achieves Binary-level compatibility and brings windows development into the component age. One of the concepts of COM, In-process components, use dynamic Connection Library as the carrier in user State. So no matter before or after com, DLL is one of the most important ways to achieve software reuse in windows. The pure DLL does not achieve binary compatibility like Com. However, unlike user code, 2000/XP does not have a mechanism similar to com to implement binary compatibility of core states. In fact, there is no need to provide a complex mechanism like ole32.dll for implementing com library in user State (simple rules followed by user State COM components are mainly hidden in the complexity of COM Library ).

The traditional DLL reuse mode is also suitable for the development of core State Code. In addition, to simplify the development of the same type of devices, Windows 2000/XP has formed the concept of class/port/miniport. We know that the. SYS file provided by the driver has no substantial changes with the DLL file. First, we will discuss the concepts of class/port/miniport and the benefits of this mechanism:
 
1. We know that PC hardware can be divided into many categories, such as storage devices. Each category is divided into many sub-categories. For example, storage devices can be divided into CDROM, tape, and harddisk. A class driver is provided for each type of devices. This type of Driver provides a set of common functions that the driver of a certain type of device has nothing to do with the device. For Driver developers, with the intervention of class driver, only some functions need to be implemented for specific devices. The functions required by the IO manager should not be directly implemented by the class driver, otherwise, the class driver calls the underlying module. The class driver is usually provided by Microsoft and is usually implemented in a device-independent part. The device-independent part mainly means that the device hardware is not operated directly. This underlying module is usually called The miniport driver, which provides services by the port driver (the port driver is similar to the user-state DLL, but she also implements some features to simplify the compilation of the device driver, for example, hide complicated operations on IRP ). The main methods for class driver to call miniport driver include device ioctl, the routines exported by class driver (that is, the DLL concept), or callback functions. In this way, the common parts can be separated to achieve the so-called reuse, which not only reduces the occupation of system resources, but also reduces the development workload. For example, for storage devices, Microsoft provides three class drivers: CDROM. sys, tape. sys, and disk. sys. Of course, these three drivers also have something in common. After all, they all belong to storage devices (the differences between underlying hardware are distinguished by miniport driver ). Windows provides classpnp. SYS. Three drivers place some common routines in this sys. This is more like the DLL reuse technology introduced at the beginning of the article, rather than the class/port or miniport driver introduced here. I define the class at the beginning of this section. In fact, I put forward a set of common functions unrelated to the device. That is, the class driver implements a part unrelated to the hardware of the device. The advantage of this is that for user-mode client programs, either for SCSI or IDE devices, we can all use the same IO operation for read/write operations. The main differences here are that the class driver distributes different requests to the corresponding port/miniport driver to achieve user transparency. This is the main purpose of the class driver. Microsoft also provides a miniclass concept, which is not described in this article (For details, refer to the relevant documentation ).

2. How does the class driver work internally? Class driver converts some standard Io operations such as irp_mj_read defined by the system into private IOCTL of devices of a specific category, and then calls the corresponding miniport driver. For example, for CDROM on the SCSI bus, CDROM converts irp_mj_read into a SCSI command to call The miniport driver provided by the system. A specific example is provided below. Since the class driver only calls the miniport driver, why should we introduce the concept of port driver? We know that there are many categories of SCSI bus controllers. If each controller designs a driver from the beginning, how difficult it is to implement such a driver. Therefore, Microsoft introduced the concept of port driver. For example, if the SCSI port driver is used to implement the shared content of all SCSI devices, miniport only implements the specific SCSI controller or SCSI device. For the shared content, you only need to call the services provided by the port driver. For example, miniport driver aha154x. sys implements the adaptec AHA-154x series SCSI controller. Her job is to process the Server Load balancer (SCSI request block, which contains the command descriptor block, that is, CDB. For details, see the SCSI standard ), other details (such as synchronization and so on) are handled by port driver scsiport. sys completed ). The class/port/miniport model exists everywhere in 2000/XP. For example, disk. sys is a disk driver, and pciidex. sys is a port driver of the IDE system. Miniport implements its functions by calling the functions exported by the port driver. In fact, there are also DLL reusable content.

It should be pointed out that class/port/miniport is not strictly independent, that is to say, it does not mean that these are strictly differentiated, and the corresponding functions are strictly implemented by three. sys. For example, atapi. sys integrates port and miniport functions to serve ide devices based on atapi (using SCSI commands. In a strict sense, network drivers such as network devices and network protocols in 2000/XP can also be called the class/port/miniport driver model. Although they have their own terms, for example, NDIS Intermediate Drivers, NDIS protocol drivers, and NDIS miniport drivers (7-layer OSI model ). I prefer to understand NDIS. sys as a set of class/port, while other NDIS miniport drivers are miniport driver.

The best way to learn class/port/miniport is to learn the source code. The above mentioned disk. sys/CDROM. sys/tape. sys/classpnp. sys/aha154x. sys provides source code in DDK. Class driver generally calls miniport driver through IOCTL. Port driver usually maintains information about The miniport driver through a memory area related to the driver (such as the device_object created ). This memory area is related to the port driver (that is, the Class Device of the same subclass, such as disk. sys/CDROM. sys/tape. sys does not interfere with each other). Here I use the TLS (Thread Local Storage) concept. TLS is thread-related. In "interpreting the hierarchical Driver Model of Windows 2000/XP", I introduced that customers (here miniport) can use ioallocatedriverobjectextension to allocate a piece of memory by the target Driver (here scsiport. sys. Either scsiport. sys or NDIS. sys organizes miniport proprietary information.

Since the header mentioned COM, I will insert a digress here. com uses coinitialize (Ex) to initialize com execute context (apartment). In fact, coinitialize (Ex) also uses Teb (thread environment block) the reservedforole field of points to a memory allocated in the heap to support the com execution environment. In XP SP1, the offset value of this field is 0xf80. This concept is the same as ioallocatedriverobjectextension's memory allocation driver, except that the former uses the FS register to query the OLE information in thread's Teb, the latter uses iogetdriverobjectextension to obtain the clientdriverextension of driver_object information.

After talking about so many concepts of class/port/miniport, it is still very abstract. We can use an example to illustrate how it may be better understood. Here we will use tools such as virtual optical drive. We know that the virtual optical drive software is usually implemented using SCSI miniport. Here we use CDROM. sys/scsiport. sys/fakmcm. sys is a class/port/miniport model. Both class driver and port driver are provided by OS. Fakmcm sys is a SCSI miniport driver implemented by me. For more information, see fakmcm for Windows 2000/XP. Copystar Fantom dvdrom, daemon tools, Virtual CD, and fakmcm for Windows 2000/XP. both sys and SCSI miniport ports use port driver scsiport. sys provides services.

Next I will observe the situation on my computer (a physical optical drive, fakmcm and daemon tools are installed at the same time:

Kd>! Devstack cdrom0
! Mongobj! Drvobj! Devext objectname
Ffaa5020/driver/Redbook ffaa50d8
> Ffaa69e0/driver/CDROM ffaa6a98 cdrom0
81340d78/driver/ACPI 8135d978 00000063
IdeDeviceP1T0L0-e 813418e8/driver/atapi 813419a0
! Devnode 812fd700:
Deviceinst is "IDE/CdRomMITSUMI_CD-ROM_SR243T _______________ l02g ____/5 & 18b54618 & 0 & 0.0.0"
Servicename is "CDROM"
Kd>! Devstack cdrom1
! Mongobj! Drvobj! Devext objectname
Ff8bfa60/driver/Redbook ff8bfb18
> Ff8bf030/driver/CDROM ff8bf0e8 cdrom1
8133b030/driver/stlth317 8133b0e8 stlth3171port0path0target0lun0
! Devnode 8133b850:
Deviceinst is "SCSI/CDROM & ven_v386 & prod_stealth_dvd & rev_1.0h/1 & 2afd7d61 & 0 & 000"
Servicename is "CDROM"
Kd>! Devstack cdrom6
! Mongobj! Drvobj! Devext objectname
> Ff5fbac8/driver/CDROM ff5fbb80 cdrom6
Ff4c9a38/driver/fakmcm ff4c9af0 fakecd1port3path0target0lun0
! Devnode ff9c68a0:
Deviceinst is "SCSI/CDROM & ven_webcrazy & prod_webcrazy_fakmcm & rev_1.00/1 & 1843 CCBC & 0 & 000"
Servicename is "CDROM"

Here, the windbg lists cdrom0, cdrom1, and cdrom6 virtual optical Drives Used for the service physical drive, daemon tools, and fakmcm. They are all composed of/driver/CDROM (that is, class driver CDROM. sys) the object created by the driver, which is located at the top layer of the driver stack (Redbook is only a filter driver used to implement functions related to audio, which is not considered here ), in this way, the I/O manager only has a "CDROM", regardless of whether the underlying layer is a physical drive (on the IDE Bus) or a virtual drive (on the virtual SCSI bus ). This is the role of the class driver. In fact, the interaction with the file system is also implemented by the class driver. Therefore, fakmcm does not need to consider file system, that is to say, I do not have a line of code in fakmcm for formats such as ISO files. Many of my friends have sent letters and asked me to answer these questions.

The cdrom0 of atapi. sys, which implements the port/miniport function together, is used to serve the physical optical drive (atapi IDE), which is easy to understand here. For virtual SCSI bus optical drives such as cdrom1, cdrom6, the underlying miniport driver of the device stack is run by port driver scsiport. in other words, the port driver only provides an environment (just as ole32.dll works for com ). CDROM. sys converts the standard IRP to a SCSI-Based Server Load balancer (CDB) and then uses IOCTL to call the lower-layer miniport to complete the IO request. In fact, miniport generally calls the routines provided by the port driver to generate the device object. For example, scsiport. sys provides scsiportinitialize, so the port driver always knows the device information it manages. In fact, the port driver generally hides the use of device object and IRP from The miniport driver developer in the 2000/XP environment. Miniport driver provides the callback function to simplify the operations of developers.

Let's continue to look at the content of the fakmcm sys driver object:

Kd>! Drvobj fakmcm 2
Driver object (ff3d5208) is:
/Driver/fakmcm
DriverEntry: f9a50466
Driverstartio: f94930c4 scsiport! Scsiportstartio
Driverunload: f949d3e0 scsiport! Scsiportunload

Dispatch routines:
[00] irp_mj_create f9490436 scsiport! Scsiportglobaldispatch
[01] irp_mj_create_named_pipe 804f986f nt! Iopinvaliddevicerequest
[02] irp_mj_close f9490436 scsiport! Scsiportglobaldispatch
[03] irp_mj_read 804f986f nt! Iopinvaliddevicerequest
[04] irp_mj_write 804f986f nt! Iopinvaliddevicerequest
[05] irp_mj_query_information 804f986f nt! Iopinvaliddevicerequest
[06] irp_mj_set_information 804f986f nt! Iopinvaliddevicerequest
[07] irp_mj_query_ea 804f986f nt! Iopinvaliddevicerequest
[08] irp_mj_set_ea 804f986f nt! Iopinvaliddevicerequest
[09] irp_mj_flush_buffers 804f986f nt! Iopinvaliddevicerequest
[0a] irp_mj_query_volume_information 804f986f nt! Iopinvaliddevicerequest
[0b] irp_mj_set_volume_information 804f986f nt! Iopinvaliddevicerequest
[0C] irp_mj_directory_control 804f986f nt! Iopinvaliddevicerequest
[0d] irp_mj_file_system_control 804f986f nt! Iopinvaliddevicerequest
[0e] irp_mj_device_control f9490436 scsiport! Scsiportglobaldispatch
[0f] irp_mj_internal_device_control ffa408e8 + 0xffa408e8
[10] irp_mj_shutdown 804f986f nt! Iopinvaliddevicerequest
[11] irp_mj_lock_control 804f986f nt! Iopinvaliddevicerequest
[12] irp_mj_cleanup 804f986f nt! Iopinvaliddevicerequest
[13] irp_mj_create_mailslot 804f986f nt! Iopinvaliddevicerequest
[14] irp_mj_query_security 804f986f nt! Iopinvaliddevicerequest
[15] irp_mj_set_security 804f986f nt! Iopinvaliddevicerequest
[16] irp_mj_power f9490436 scsiport! Scsiportglobaldispatch
[17] irp_mj_system_control f9490436 scsiport! Scsiportglobaldispatch
[18] irp_mj_device_change 804f986f nt! Iopinvaliddevicerequest
[19] irp_mj_query_quota 804f986f nt! Iopinvaliddevicerequest
[1A] irp_mj_set_quota 804f986f nt! Iopinvaliddevicerequest
[1b] irp_mj_pnp f9a503ba fakmcm! Fakecdpnp

Obviously, for the driver entry provided by SCSI miniport, both startio, unload, and IRP dispatch functions are implemented by scsiport. sys provides (to provide full flexibility, the irp_mj_pnp entry is fakmcm. sys miniport driver is used to dynamically increase or decrease the number of CDROM ).

This article only discusses the class/port/miniport model from the application perspective, the understanding of this model and how to implement similar mechanisms are actually just the most basic concept of software reuse (of course, some of the features of writing device drivers, for example, coupling with hardware devices ). Such a model is much simpler than the binary-level multiplexing technology of user State COM. It's just because they are in the core State and easy to write blue screen that people don't know enough. This article just wants to provide you with a guide. In my opinion, there is really nothing special about it.