일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 안철수
- cluster node as Domain controller
- failover cluster
- paged pool
- windows update
- windbg
- nonpaged pool
- windows media service
- SQL Server 2012R2 FCI
- 프로세스 CPU 사용량
- MSCS on VMWare
- Xperf
- 인문고전
- FTP7.5
- 작업관리자
- 클러스터
- ftp7.5 장애조치 클러스터
- Session space
- Local TempDB
- Windows Server 2008
- Windows Server 2016
- 터키여행
- dsquery
- LiveKD
- windows debugging tool
- Hyper-V
- iSCSI target
- SQL Server 2008
- Nested VM
- Windows Server 2016 Hyper-v Cluster
- Today
- Total
류짱:Beyond MySelf
장치 드라이버 동작 원리 본문
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.