IDE Port Driver
The ATA port driver and ATA miniport driver models may be altered or unavailable in the future. Instead, we recommend using the Storport driver and Storport miniport driver models.
In Microsoft Windows NT 4.0, the port/miniport driver pair associated with the IDE bus is a SCSI miniport driver, atapi.sys, that linked to the SCSI port driver, scsiport.sys.
In Microsoft Windows 2000 and Windows XP, the IDE port driver atapi.sys is an independent driver that no longer links to scsiport.sys, nor to any other wrapper driver.
There are three system-supplied drivers in the IDE driver model for Windows 2000 and Windows XP: atapi.sys (port driver), pciidex.sys (controller driver), and pciide.sys (generic controller minidriver). All three drivers are illustrated in the following figure.
Starting from the bottom of the figure, the following describes each driver in the stack:
The IDE stack in Windows 2000 and Windows XP is layered over the PCI bus driver.
Microsoft provides a native IDE controller driver/minidriver pair that is capable of managing most IDE controllers. The IDE controller driver, pciidex.sys, handles the hardware-independent aspects of the driver pair, and the minidriver, pciide.sys, handles the hardware-dependent aspects.
Vendors can elect to provide their own IDE controller minidriver instead of using the native minidriver, pciide.sys. The vendor’s minidriver must work together with the Microsoft-supplied controller driver to form a controller-minidriver pair. See Requirements for Vendor-Supplied IDE Controller Minidrivers for an explanation of the requirements a vendor’s minidriver must fulfill to work properly with the native Microsoft controller driver.
Microsoft provides an IDE port driver, atapi.sys, which is also known as the channel driver, because it creates and manages a functional device object (FDO) for each IDE channel. The port driver is layered above the IDE controller/minidriver pair. It translates the SCSI request blocks (SRB) that it receives from the storage class driver into the format required by the underlying IDE controller. In particular, the command descriptor blocks (CDB) contained within an SRB are defined differently for ATAPI and SCSI devices. The port driver repackages CDBs to make them compatible with the ATAPI transport protocol, thereby insulating upper-level drivers from peculiarities of the IDE bus.
Microsoft provides a CD-ROM class driver capable of managing all CD-ROM (type 5 SCSI) devices.
To see a diagram of the device object stack corresponding to the driver stack in the previous figure, see Device Object Example for a PCI IDE Controller.
In Windows Vista and later versions of the operating system, the IDE stack is managed by the ATA Port Driver.
Introduction to Storage Port Drivers
Microsoft Windows contains three system-supplied storage port drivers:
Storport Driver (Storport.sys), available in Windows Server 2003 and later versions of the operating system (recommended)
ATA Port Driver (Ataport.sys), available in Windows Vista and later versions of the operating system
The Storport driver is a more efficient, higher performance driver than SCSI Port. Therefore you should develop miniport drivers that work with the Storport driver whenever possible. It is particularly important to use Storport with high performance devices, such as host-based RAID and fibre channel adapters. Storport cannot be used with adapters or devices that do not support Plug and Play (PnP) or that must use system DMA. For a detailed list of restrictions on the use of the Storport driver, see Requirements for Using Storport with an Adapter.
The ATA port driver shields an ATA miniport driver from the SCSI-based protocol that the port driver uses to communicate with higher-level drivers, such as storage class drivers. For instance, miniport drivers that are attached to either SCSI port or Storport must provide SCSI sense data to the port driver. This is not necessary for an ATA miniport driver. The ATA port driver collects the necessary data from the ATA miniport driver by using ATA commands, organizes the data so that it conforms to a SCSI sense data format, and passes the data on to higher-level drivers as though it were SCSI sense data. The ATA port driver also converts each SCSI_REQUEST_BLOCK that it receives from higher-level drivers into an ATA-based equivalent called an IDE_REQUEST_BLOCK.
Each port driver communicates with a set of vendor-supplied storage miniport drivers and supplies a set of support routines for the miniport drivers to call. Each port driver communicates with its miniport drivers by calling a standard set of routines that every storage miniport driver must implement. The miniport driver routines called by the SCSI port driver, the Storport driver, and the ATA port driver are very similar to one another. Lists of port driver support routines and miniport driver routines can be found in the following sections:
| Port Driver | Support Routines | Miniport Driver Routines |
|---|---|---|
| Storport driver | Storport Driver Support Routines | Storport Driver Miniport Routines |
| SCSI Port driver | SCSI Port Driver Support Routines | SCSI Miniport Driver Routines |
| ATA port driver | ATA Port Driver Support Routines | ATA Miniport Driver Routines |
If you want your storage device to be supported on client Windows products, or on server products earlier than Windows Server 2003, you must supply a SCSI Port miniport driver.
If you want your storage device to be supported on Windows Server 2003 and later versions of the server product family, you can provide either a Storport miniport driver or a SCSI miniport driver. If you wish to install an ATA storage device in Windows Vista and later versions of the operating system, you must provide an ATA port miniport driver.
The sections that follow describe the Storport, SCSI Port, and ATA port drivers and how they differ.
Storport Driver
In addition to the SCSI Port driver, Microsoft Windows Server 2003 and later versions provide Storport (storport.sys), a storage port driver that is especially suitable for use with high-performance buses, such as fibre channel buses, and RAID adapters.
There are several advantages to using Storport rather than the SCSI Port driver:
Improved performance, both in terms of throughput and the system resources that are utilized.
Improved miniport driver interface that addresses the needs of high-end storage vendors, particularly host-based RAID and fibre channel vendors.
All vendors are encouraged to use Storport where possible, rather than the SCSI Port driver. Certain restrictions apply, however. Storport cannot be used with adapters or devices that do not support Plug and Play. All DMA devices must have bus-mastering DMA capability, because Storport does not support programmed I/O or subordinate-mode DMA. Other restrictions apply in regard to tagged queuing, autorequest sense, WMI support, the sort of SCSI inquiry data that devices must report, and booting directly from an adapter’s ROM BIOS. For a detailed list of restrictions on the use of the Storport driver, see Requirements for Using Storport with an Adapter.
To better utilize the investment that vendors have made in SCSI Port miniport drivers, Storport follows the SCSI Port-miniport driver architecture with very few modifications. Changes to the SCSI Port driver interface were made in areas where new algorithms were able to produce measurable speed increases, or where it was necessary to add support for high-speed buses.
Windows Storage Driver Architecture
Windows operating system class and filter drivers for peripheral storage devices act as an interface between any intermediate or highest level drivers layered above the class or filter driver and a system-supplied port driver.
I/O requests from a user application or kernel component reach storage class drivers through I/O System Services and one or more intermediate or highest level drivers, such as a file system driver. Storage class drivers translate the standard IRPs they get into IRPs with system-defined SCSI request blocks (SRBs) containing SCSI command descriptor blocks (CDBs) before sending each IRP on to the next-lower driver. A storage port driver translates SRBs from class drivers into bus-specific commands which it sends to the storage HBA, through an I/O bus driver and possibly one or more filter drivers.
The following figure shows the layered architecture of Windows storage drivers.
Starting from the bottom of the figure, the following describes each type of storage driver:
A storage port driver defines an interface to all Windows storage class drivers, including the system-supplied disk, tape, CDROM, DVD, and changer class drivers. This port/class interface insulates class drivers from adapter-specific requirements of the host bus adapter to which their respective devices are connected. A storage port driver also synchronizes access to the bus for all drivers of devices on the corresponding HBA. The system supplies storage port drivers for SCSI, IDE, USB and IEEE 1394 adapters.
A storage port driver receives SRBs from the next higher driver (a storage class driver or intervening filter driver) and processes them as follows:
- The storage port driver for a SCSI, or other bus, passes SRBs with CDBs on to an operating system-independent, HBA-specific Storport miniport driver , which is dynamically linked to its corresponding port driver and provides hardware-specific support for a particular HBA. For information about implementing a SCSI miniport driver, see Storport Miniport Drivers.
- The storage port driver for a legacy IDE/ATAPI or IEEE 1394 bus translates the SRBs received from the storage class driver into the format required by the underlying adapter—for example, repackaging CDBs according to a bus-specific transport protocol, or translating them into a different format, thereby insulating upper level drivers from peculiarities of the underlying bus.
An upper or lower storage filter driver supports device-specific functionality not provided by a system-supplied storage class driver. A lower filter storage driver monitors SRBs and/or IRPs issued by a storage class driver and modifies them as needed before passing them to the next-lower driver (a storage port driver or another storage filter driver).
For information about implementing a storage filter driver, see Storage Filter Drivers.
A storage class driver uses the SCSI port/class interface to control a device of its type on any bus for which the system provides a storage port driver. A class driver is specific to a particular class of device—for example, one class driver can run all CD-ROM devices on any supported bus; another can control all disk devices. The storage class driver handles I/O requests from user applications or drivers higher in the storage stack by building SRBs containing CDBs and issuing those SRBs to the next-lower driver (a storage port driver or intervening filter driver), just as if the device were a SCSI device.
The implementation of a storage class driver is transparent to upper level drivers. A class driver for a tape or medium changer device is implemented as a device-specific miniclass driver that links to a system-supplied class driver. System-supplied class drivers for other storage devices, such as disk and CD-ROM/DVD, are implemented as single monolithic drivers.
For information about implementing a storage class driver, see Storage Class Drivers. For information about implementing a tape or changer miniclass driver, see Tape Drivers and Changer Drivers, respectively.
An upper filter storage driver intercepts IRPs from user applications and drivers higher in the storage stack and then possibly modifies them before passing them to the next-lower driver (a storage class driver or another storage filter driver). Filter drivers typically monitor performance of the underlying device.
The type of bus to which a device is attached and the implementation of its storage port driver are transparent to upper level drivers. A storage port driver might be implemented according to the port/miniport driver architecture, like the SCSI port driver; as a monolithic driver that controls a single, standard piece of hardware, such as the IDE/ATAPI port driver; or as a filter driver that translates SRBs into the format required by a different driver stack, such as the IEEE 1394 port driver.
The system-supplied SCSI port driver can also act as an interface between a storage class driver and a SCSI miniport driver that controls a non-SCSI storage device of the same type. For example, rather than writing a driver for a new disk-array controller, a driver writer can save considerable design, development, and debugging effort by writing a pseudo-SCSI miniport driver that links to the system SCSI port driver and uses the interface it provides. Such a miniport driver is required to translate incoming SCSI commands into device-specific commands. On the other hand, the system-supplied port and class drivers handle much necessary work on a pseudo-SCSI miniport’s behalf, including registry accesses during initialization, all resource and object allocations, synchronization, presizing of requested transfers to suit the capabilities of the miniport’s device, and retrying requests.
For more detailed information about SRBs, see the Kernel-Mode Driver Architecture Reference. For device-type-specific information about CDBs, consult appropriate command sets in the INCITS SCSI-3 standards.
Introduction to Storage Class Drivers
A storage class driver uses the well-established SCSI class/port interface to control a mass storage device of its type on any bus for which the system supplies a storage port driver (currently SCSI, IDE, USB and IEEE 1394). The particular bus to which a storage device is connected is transparent to the storage class driver.
Any storage class driver handles I/O requests from user applications or higher-level drivers by building SCSI request blocks (SRBs) containing command descriptor blocks (CDBs) and sending them, through any intervening filter drivers, to the underlying storage port driver.
A storage class driver does not provide addressing information in the SRB. Instead, the port driver (or a still-lower driver) is responsible for any addressing required. The storage port driver translates the SRBs into the format required by the underlying host bus adapter (HBA), which might be a SCSI or 1394 host bus adapter, IDE controller, or other such hardware, and issues commands to the device. In the Windows Driver Kit (WDK), the term «HBA» stands for any such underlying adapter or controller.
To the I/O manager and any higher-level drivers layered above a storage class driver, most storage class drivers are standard kernel-mode intermediate drivers. Thus every class driver must have a DriverEntry routine, an AddDevice routine, an Unload routine, one or more IoCompletion routines, plus DispatchPnP and DispatchPower routines to handle Plug and Play and power IRPs.
A storage class driver must also have a DispatchSystemControl routine to handle system-control IRPs, and can have any other standard higher-level driver routine, such as a StartIo routine, as determined by the driver designer. For more information about system-control and standard kernel-mode driver routines, see Standard Driver Routines.
To the PnP manager, a storage class driver is a Function Drivers, that is, one that drives an individual device. A storage class driver can also act as a Bus Drivers, enumerating child devices of its devices. For example, the class driver for a partitioned media device such as a disk returns a list of PDOs representing its partitions. Each such PDO can be addressed as a target device and be serviced by its own class driver.
A driver for a SCSI device such as a printer or a scanner should be implemented as described in this section. A driver for such a SCSI device utilizes the same SCSI class/port interface to control its device and has the same responsibilities to handle IRPs, build SRBs, and send them to the underlying port driver as does a driver for a storage device.
