류짱:Beyond MySelf

장치 드라이버 동작 원리 본문

Microsoft/Windows Platform

장치 드라이버 동작 원리

リュちゃん 2010. 11. 29. 16:40

How Device Drivers Work

http://technet.microsoft.com/en-us/library/cc776371(WS.10).aspx

 

Device Driver Architecture

The Windows Server 2003 I/O system provides a layered architecture for serial device drivers, consisting of the drivers and their corresponding device objects.

Plug and Play Drivers

Plug and Play supports three types of drivers:

  • Function drivers, which drive individual devices
  • Filter drivers, which filter I/O requests for devices, classes of devices, and buses
  • Bus drivers, which service bus controllers, adapters, and bridges

The most common bus driver types are PCI, PnP ISA, SCSI, and USB. During enumeration, a bus driver identifies the devices on its bus and creates device objects for them.

Device Objects

A driver creates a device object (DO) for each device it controls; the device object represents the device to the driver. Plug and Play recognizes three types of device objects:

  • Physical device objects (PDOs), which represent individual devices on a bus to a bus driver
  • Functional device objects (FDOs), which represent individual devices to a function driver
  • Filter device objects (filter DOs), which represent individual devices to a filter driver

The following figure shows a chain of attached device objects and drivers for a Plug and Play device.

Device Objects in a Device Stack

The device stack includes a device object for each driver involved in handling the I/O to a particular device.


Components for Device Objects in a Device Stack

Component

Description

Lower-level filter driver

Optional filter driver, loaded after the bus driver and any bus driver filters. There are two types of filters, device-specific and per-class. A lower-level device-specific filter monitors and/or modifies I/O requests to a particular device; typically, such filters redefine hardware behavior to match specifications. A lower-level per-class filter monitors and/or modifies I/O requests for a class of devices; for example, a lower-level class filter driver for mouse devices could provide acceleration, performing a nonlinear conversion of mouse movement data.

Upper-level filter driver

Optional filter driver, loaded after the function driver, which attaches its device object above the FDO. There are two types of upper-level filters, device-specific and per-class. An upper-level device filter driver adds value for a particular device; for example, an upper-level device filter for a keyboard could enforce additional security checks. An upper-level per-class filter adds value for all devices of a particular class.

 

For Plug and Play devices, the device object at the bottom of the device stack is the PDO created by the underlying bus driver. The FDO is created by the function driver for the device. Filter DOs are attached above and below the FDO.

The PDO is created by the underlying bus driver when it enumerates the device. The FDO and filter DOs are created by FDOs or filter DOs for devices enumerated by the Plug and Play Manager

Device Driver Physical Structure

The following figure shows how device drivers operate in both kernel mode and user mode.

Device Driver Physical Structure

The following table describes the components of the preceding Device Driver Physical Structure diagram.

Components for Device Drivers

Component

Description

Win32 API

32-bit application programming interface for Windows operating systems that initiates I/O operations through Ntdll

Ntdll

Function library that exposes stubs that invoke Windows system calls (like NtReadFile below) as exported functions

NtReadFile

I/O Manager system call that creates an I/O request packet and directs it to the appropriate driver

I/O Manager

Subsystem that controls and interacts with all devices on the system and provides routines that drivers can call to have the I/O Manager insert IRPs into the associated device queue

IRP

I/O Request Packet sent by I/O Manager to request services from a driver

IoCallDriver

Routine that sends an IRP to the driver associated with a specified device object

 

Once the request has been processed, the outcome is one of three results:

Queue for later process

The device driver defers the request processing to a later time; for example, when necessary resources are available, or the device is not busy.

Send to hardware port

The device driver programs the hardware to perform the operation specified in the request.

Send to another device driver

The device driver sends the request to another device driver; for example, if the request parameters change.

New Storage Device Drivers in Windows Server 2003

New and updated storage device drivers are available for Windows Server 2003, including drivers for iSCSI and Multipath I/O (MPIO) technologies. Windows Server 2003 also includes a new port driver model, Storport.

Storage architecture consists of a series of layered drivers, as shown in the following figure. When a storage device is added, each layer is responsible for ensuring that the disk is functional.

Windows Storage Stacks

The following table describes the components of the previous diagram.

Windows Storage Stacks Components

 

Component

Description

I/O Subsystem

Sends I/O requests to the file system.

File System

Structure of a disk, either FAT or NTFS. File systems access and manage all data on the disk, including information about the structure of the disk itself.

Volume Snapshot

Manages software snapshots.

Volume Manager

Presents volumes to users; supports basic and dynamic disks.

Partition Manager

Manages disk partitions.

Class

Manages specific devices types, such as disks and tapes.

Port

Manages specific transports, such as SCSIport or Storport.

Miniport

Vendor-supplied functionality linked to a specific port driver. Manages hardware-specific details.

Disk Subsystem

Disk processes such as read/write.

Device Stack

Stack layers that manage storage devices.

Driver Stack

Chain of drivers that support the operations of a device.

Storport

The Storport driver is new to Windows Server 2003. Storport implements an architecture designed for better performance for RAID systems and in Storage Area Network (SAN) environments. Storport delivers higher I/O throughput, enhanced manageability, and an improved miniport interface. Storport better utilizes faster adapters through the use of reduced Delay Procedure Call (DPC) and improved queue management.

iSCSI

Internet Small Computer System Interface (iSCSI) is an alternative to Fibre Channel protocols. iSCSI is used to transfer data storage over long distances, making it a key contributor to the advancement and growth of storage area networks (SANs). iSCSI is also used to transmit data over local area networks (LANs), wide area networks (WANs), or the Internet.

Microsoft released the Microsoft iSCSI Software Initiator in June 2003 for Windows 2000, Windows XP, and Windows Server 2003. The Microsoft iSCSI Software Initiator is not included with Windows Server 2003, but you can download the driver from the Microsoft Download site. Customers should ensure that the hardware included in their iSCSI solution has passed the Designed for Windows Logo Program qualification tests.

Multipath I/O

Microsoft Multipath I/O architecture allows hardware manufacturers to develop highly available storage devices that can be added easily to a computer running Windows 2000 or Windows Server 2003. The Multipath I/O (MPIO) DDK consists of three standard drivers plus a fourth, device-specific driver that a storage vendor will use to create a Microsoft MPIO solution that works with the specific storage array it supports.

Microsoft MPIO enables the use of multiple physical paths from a server to a storage device. A physical path includes adapters, cables, and switches that connect the storage device to the server. In the event that one of the components in a path fails, all subsequent I/O is routed over an alternate path, providing applications uninterrupted access to the data on the storage device. In addition, Microsoft MPIO can be used to balance I/O operations over these paths using methods and algorithms defined by the storage vendor.