Detailed explanation of Windows 2000 / XP Class / Port / MiniPort drive model
Webcrazy (http://webcrazy.yeah.net)
For software multiplexing, Microsoft Windows provides Com (Component Object Model) in the user layer, which implements compatibility of the binary level, making Windows development into the component era. One of the concepts of the COM, in the process, using a dynamic link library as a carrier in a user-mode. So, whether before or after COM, the DLL is one of the most important ways to implement software reuse under Windows. The simple DLL does not implement COM-based binary compatibility purposes. However, for driver developers, different from the code of the user state, 2000 / XP does not have the corresponding mechanism like COM, and realize the binary compatibility of the core state. In fact, it is actually not necessary to provide a complex mechanism such as OLE32.DLL in a user-mounted COM library (simple rules followed by the User COM component mainly hide the complexity of COM Library).
The traditional DLL multiplexing mode is also applicable to the development of core state code. In order to simplify the purpose of simplifying the same type of device development, Windows 2000 / XP forms a concept of Class / Port / MiniPort. We know that there is no substantial change in the actual DLL provided by Driver. We first discuss the concept of Class / Port / MiniPort and the benefits of this mechanism:
1. We know that the PC hardware can usually be divided into many large classes, such as storage devices, and more. The major categories are divided into many small classes. If stored, it can be divided into CDROM, TAPE, HARDDisk, and more. For each type of device, a Class Driver is provided. Such a DRIVER implements a common functional set of a type of device Driver and device. For Driver developers, there is a Class Driver intervention, just need to implement a part of the functionality that needs to be used. The function you need to do is done directly by Class Driver. To pass the Class Driver by calling the underlying module by calling the underlying module achieve. Class Driver is usually provided by Microsoft, usually implemented, and the device is independent, and the equipment is not mainly referred to whether the device hardware is not directly operating. The underlying module is often referred to as MiniPort Driver, the latter provides services by Port Driver (Port Driver is similar to the user-state DLL, but she also implements features that simplify the device driver, such as hiding the cumbersome operation of IRP, etc.). Class Driver Call the MINIPORT DRIVER mode mainly has Device IOCTL, Class Driver exported routines (the concept of DLL) or by callback functions, and more. Such a common portion is separated, that is, so-called multiplexing can reduce the occupation of system resources, and the development workload is reduced. For example, the storage class device Microsoft provides three Class Driver for cdrom.sys, Tape.sys, with Disk.sys, respectively. There is also a common point in these three Driver, after all, they all belong to the storage class (the difference between the underlying hardware is distinguished by miniPort Driver). Windows provides classpnp.sys, and three Driver places some universal routines in this SYS. This is more like a DLL multiplexing technology that is introduced by the article, not the Class / Port introduced here or MiniPort Driver. I started to define the Class in this segment that Class actually specifically proposes a collection of common functions that are independent of the device. That is, Class Driver is unrelated to the device hardware. The benefits of doing this are for client-state customer programs, regardless of the same IO operations for read and write regardless of the device of SCSI or IDE, we can use the same IO operation. The main difference from this is divided by Class Driver to the corresponding PORT / MiniPort Driver to implement transparency to the user. This is the purpose of the most important Class Driver. Microsoft also provides a concept of Miniclass, which is not described herein (please refer to the relevant documentation for details).
2, then how Class Driver is usually working? Class Driver mainly converts some standard IO operations defined by system to a private IOCTL of a particular category device, and then calls the corresponding MiniPort Driver. For example, for CDROM on the SCSI bus, CDROM converts IRP_MJ_READ into a SCSI command calling system for miniPort Driver, which will use a specific example instructions. Since Class Driver just calls MiniPort Driver, why do you want to introduce the concept of port driver? We know that there are many categories of the SCSI bus controller, and if each controller begins with a DRIVER from the beginning, a Driver that implements such a Driver will be a difficult thing. So Microsoft introduced the concept of port driver. For example, by SCSI Port Driver implementing all SCSI common content, MiniPort only implements content such as a specific SCSI controller or SCSI device, and a shared part can call the service provided by Port Driver. For example, the Adaptec AHA-154X Series SCSI controller is implemented as MINIPORT Driver Aha154x.sys. Her mission is only to process SRB ((SCSI Request Block, including Command Descriptor Block, That is, CDB, please refer to SCSI standard), other detail issues (such as steps, etc. are completed by port driver scsiport.sys) .CLASS / Port / MiniPort model exists in 2000 / XP, such as disk.sys is disk class driver, and pciidex.sys is the port driver of the IDE system. MINIPORT implements its function by calling port driver exported functions, here. There are DLL multiplexed content. Need to point out that Class / Port / MiniPort is not a strict independent body, which means that these strict distincts are strict, strictly constructed by three .sys to achieve corresponding respectively. The function. If Atapi.sys combines port and miniport function, she is used to serve the IDE device based on ATAPI (using SCSI commands). Network devices such as network devices, network protocols, etc. in XP, from strict sense It can also be said to be the drive model of Class / Port / MiniPort, although they have their own terms, such as NDIS Intermediate Drivers, Ndis Protocol Drivers and NDIS Protocol Drivers, etc. (used to implement OSI 7-layer model). I am more willing Understand NDis.sys is a collection of Class / Port, while the remaining NDIS MiniPort Drivers are MinIport Driver.
The best way to learn Class / Port / MiniPort is to learn from the source code. The disc.sys / CDrom.sys / tape.sys / classpnpnp.sys / aha154x.sys mentioned above provides source code in Microsoft in DDK. Class Driver usually calls MiniPort Driver via IOCTL. Port Driver typically maintains its information for MiniPort Driver (such as established device_Object, via a DRIVER-related memory area. This memory area is PORT DRIVER related (i.e., the Class device of the same subclass, such as disk.sys / cdrom.sys / tape.sys, uninterrupted), here I borrowed the concept of TLS (Thread Local Storage), TLS is thread related. In "Interpretation of Windows 2000 / XP Layer Drive Model" I introduced the customer (hereini) to assign a memory using IOAllocatedRiveRObjectExtension, which is directed by the destination Driver (here is the DriverDriveRextension of Driver_Object) of Driver_Object of SCSIPORT.SYS. Whether it is SCSIPORT.SYS or NDIS.sys, MINIPORT is organized. Since the article mentions com, I am inserting an external question, COM uses Coinitialize (EX) to initialize COM Execute Context (Apartment), and actually Coinitialize (EX) also uses the ReservedForole field of Teb (thread environment block) to point to the heap One of the allocated memory is used to support the COM execution environment. The offset value of this field in XP SP1 is 0xF80. Such a concept is the same as the IOALLOCATEDRIVEROBJECTEXTENSION assignment DRIVER, but only the former uses the FS register to check OLE information in the TEB of the thread, and the latter uses IOGETDRIVEROBJECTEXTension to get the ClientDriveRextension of DriveRextence information in Driver_Object.
Said that the concept of such Class / Port / MiniPort is still very abstract. We pass an example to illustrate the possibility of understanding. Here you need to use virtual CD-ROM-driven tools to explain that we know that virtual drive software usually uses SCSI MiniPort to learn from CDROM.SYS / SCSIPORT models. Just learn this with CDROM.SYS / SCSIPORT model. The Class Driver and Port Driver are provided by OS. Fakecd.sys is an SCSI MiniPort Driver I implemented. Please refer to "Fakecd for Windows 2000 / XP" for details. "Fakecd for Windows 2000 / XP" CopyStar Fantom DVDROM, Daemon Tools, Virtual CDs are the same as Fakecd.sys, all of which are served by Port Driver ScsiPort.sys.
Below I observe in our machine (with a physical optical drive, Fakecd and Daemon Tools):
KD>! Devstack CDROM0
DEVOBJ! Drvobj! Devext Objectname
FFAA5020 / Driver / RedBook FFAA50D8
> FFAA69E0 / Driver / CDROM FFAA6A98 CDROM0
81340D78 / driver / ACPI 8135D978 00000063
813418E8 / Driver / ATAPI 813419A0 IDEDEVICEP1T0L0-E! Devnode 812fd700:
DeviceInst is "IDE / CDROMMITSUMI_CD-ROM_SR243T ___________________ l02g ____ / 5 & 18b54618 & 0 & 0.0.0"
ServiceName Is "CDROM"
KD>! Devstack CDROM1
DEVOBJ! Drvobj! Devext Objectname
FF8BFA60 / Driver / RedBook FF8BFB18
> FF8BF030 / Driver / CDROM FF8BF0E8 CDROM1
8133B030 / Driver / StltH317 8133B0E8 Stlt3171port0Path0Target0lun0
DEVNODE 8133B850:
DEVICEINST IS "SCSI / CDROM & VEN_V386 & PROD_STEALTH_DVD & R_1.0H / 1 & 2AFD7D61 & 0 & 000"
ServiceName Is "CDROM"
KD>! Devstack CDROM6
DEVOBJ! Drvobj! Devext Objectname
> Ff5fbac8 / driver / cdrom ff5fbb80 CDROM6
FF4C9A38 / DRIVER / FAKECD FF4C9AF0 FAKECD1PORT3PATH0TARGET0LUN0
DEVNODE FF9C68A0:
DeviceInst Is "SCSI / CDROM & VEN_WEBCRAZY & PROD_WEBCRAZY_FAKECD & Rev_1.00 / 1 & 1843ccbc & 0 & 000"
ServiceName Is "CDROM"
Here Windbg lists CDROM0, CDROM1 and CDROM6 are used to serve physical optical drives and DAEMON Tools and FakeCD virtual optical drives. They are all-driven by / driver / cdrom.sys, and the top level of the drive stack (RedBook is just a Filter Driver for implementing the function about Audio, which is not considered here), which is now It is only a "CDROM" for IO Manager, regardless of the underlying specific physical optical drive (on the IDE bus) or a virtual optical drive (located on the virtual SCSI bus). This is the role of Class Driver. In fact, the interaction of the file system is also implemented by the Class Driver, so FAKECD does not have to consider the file system, which means that there is no line of code in Fakecd for the format of ISO files. This makes a lot of friends to ask questions, and answer here.
CDROM0 for the PORT / MiniPort feature is used to serve the physical optical drive (ATAPI IDE), which is easier to understand here. For the optical drive of the virtual SCSI bus such as CDROM1, CDROM6, the bottom of the MINIPORT DRIVER of the Type, the PORT DRIVER SCSIPORT.SYS is provided, in other words, the port driver just provides an environment (just like ole32.dll's role is the same for COM) . CDROM.SYS conversion standard IRP is SCSI's SRB (CDB) and then uses the IOCTL call to complete the IO request. In fact, MiniPort typically calls the routines provided by Port Driver to generate the Device object, such as SCSIPORT.SYS provides SCSIPORTINITIALIZE, so Port Driver knows that you manage the device information. In fact, Port Driver will generally hide the MiniPort Driver developers in 2000 / XP. Use Device Object, IRP, etc. The Callback function is provided by MiniPort Driver to complete the operation and simplify the developer's work. Let's continue to look at the contents of the fakecd.sys driver object:
KD>! Drvobj Fakecd 2
Driver Object (ff3d5208) is for:
/ Driver / fakecd
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_INFORMMATION 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_CLANUP 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 FAKECD! FAKECDPNP
Very obvious for the Driver entry provided by SCSI MiniPort, whether it is Startio, unloaded is provided by SCSIPORT.SYS (in order to provide sufficient flexibility, IRP_MJ_PNP portal is replaced by fakecd.sys miniport Driver for implementation of dynamic implementation The number of CDROMs is increased or decreased).
This article only discusses the model of Class / Port / MiniPort from an application, understanding of this model and how similar mechanism is actually just a most basic software multiplexed concept (of course, some features of writing device drivers) Such as coupling with hardware devices, etc.). Such a model is relatively simple than the multiplex technologies of the binary level relative to the user-state COM. Just because they are in the core state, writing easy Blue Screen, is not enough to know, this article is just a guidance for you, in my opinion, there is no special content.
