Ch. 9 I/O System

Ch. 9 I/O SystemCh. 9 I/O System

발표자 : 서우석발표일 : 2006 년 11 월 6 일

목차목차

I/O System ComponentsDevice DriversI/O ProcessingThe Plug and Play (PnP) ManagerThe Power ManagerConclusion

목차목차


Design GoalDesign Goal

Provide an abstraction of devices to apps.Features

High performance asynchronous packet-based I/O Services support High-Level language and different machine architectureLayering and extensibility Dynamic loading and unloading of device drivers Support for Plug and Play Support for power management Support for multiple installable file systems Windows Management Instrumentation

I/O System ComponentsI/O System Components

I/O ManagerI/O Manager

The Core of the I/O SystemI/O System is packet driven

Presented by an I/O Request Packet (IRP)Create Passing (Forwarding ) Disposing

Supply common codeIndividual drivers become simpler and more compact.

Other featuresManages buffers for I/O requestsProvides timeout supportRecords installable file systemsCommon routinesAsynchronous I/O

Typical I/O ProcessingTypical I/O Processing

Abstracts all I/O requests as operations on a virtual file, even if it is not a file.

virtual files refers to any source or destination for I/Oopen, close, read, write functions

The flow of a typical I/O requestThe flow of a typical I/O request

목차목차


Types of Device DriversTypes of Device Drivers

user-mode driversVirtual device drivers to emulate 16-bit MS-DOS appPrinter drivers

kernel-mode driversFile system drivers Plug and Play drivers Non–Plug and Play drivers

ex) network API and protocol drivers

WDM Drivers WDM Drivers

support for Windows power management, Plug and Play, and WMI Types of WDM drivers

Bus drivers manage a logical or physical busex) PCMCIA, PCI, USB, IEEE 1394, and ISAdetecting and informing the PnP manager of devices attached to the bus

Function drivers with the most knowledge about the operation of the device Filter drivers logically layer above or below function drivers, augmenting or changing the behavior of a device or another driver

ex) keyboard capture driver

Layered Drivers Layered Drivers

Class driversimplement the I/O processing for a particular class of devices, such as disk, tape, or CD-ROMwhere the hardware interfaces have been standardized and so one driver can serve devices from a wide variety of manufacturers

Port driversimplement the processing of an I/O request specific to a type of I/O port, such as SCSIimplemented as kernel-mode libraries of functions

Miniport driversmap a generic I/O request to a type of port into an adapter type, such as a specific SCSI adapter

Example: How device drivers workExample: How device drivers work

Example: Adding a layered driver Example: Adding a layered driver

EXPERIMENT: Viewing the Loaded Driver ListEXPERIMENT: Viewing the Loaded Driver List

Key driver-function routinesKey driver-function routines

fills in system data structures to register the rest of the driver's routines with the I/O manager and performs any global driver initialization that's necessary

The PnP manager sends a driver notification via this routine. driver typically allocates a device object

the main functions that a device driver provides

initiate a data transfer to or from a device. This routine is defined only in drivers that rely on the I/O manager to queue its incoming I/O requests

When a device interrupts, the kernel's interrupt dispatcher transfers control to this routine. Only drivers for interrupt- driven devices have ISRs; a file system driver, for example, doesn't have one.

DPC routine executes at a lower IRQL (DPC/dispatch level) than that of the ISR

Other routinesOther routines

One or more I/O completion routinesnotify it when a lower-level driver finishes processing an IRP

A cancel I/O routine I/O operation can be canceled

An unload routine I/O manager can remove drivers from memory

A system shutdown notification routine allows driver cleanup on system shutdown

Error-logging routines When unexpected errors occur (for example, when a disk block goes bad), a driver's error-logging routines note the occurrence and notify the I/O manager

Driver Objects and Device Objects Driver Objects and Device Objects

driver objectrepresents an individual driver in the system The I/O manager obtains the address of each of the driver's dispatch routines (entry points) from the driver object

device object represents a physical or logical device on the system and describes its characteristics

Create driver object calls the driver's initialization routine create device objects to represent devices (Most PnP drivers create devices with add-device routines, optionally assign the device a name (\Device)) unload

Location of Device objectLocation of Device object

Symbolic link make it possible for applications to open the device object in the \Global?? directory Non–Plug and Play and file system drivers typically create a symbolic link with a well-known name

ex) \Device\Hardware2 IoRegisterDeviceInterface

determines the symbolic link that is associated with a device instance

SetupDiEnumDeviceInterfaces enumerate the interfaces present for a particular GUID and to obtain the names of the symbolic links

SetupDiGetDeviceInterfaceDetail obtain additional information about the device

EXPERIMENT: Looking at the \Device Directory EXPERIMENT: Looking at the \Device Directory

The driver object The driver object

EXPERIMENT: Displaying Driver and Device Objects EXPERIMENT: Displaying Driver and Device Objects

Opening Devices Opening Devices

File objects the kernel-mode constructs for handles to files or devicessystem resources that two or more user-mode processes can share have names protected by object-based security support synchronization

File Object Attributes File Object Attributes

FILE_OBJECT in Ntddk.h

Attribute Purpose

Filename Identifies the physical file that the file object refers to

Current byte offset Identifies the current location in the file (valid only for synchronous I/O)

Share modes Indicate whether other callers can open the file for read, write, or delete operations while the current caller is using it

Open mode flags Indicate whether I/O will be synchronous or asynchronous, cached or noncached, sequential or random, and so on

Pointer to device object Indicates the type of device the file resides on

Pointer to the volume parameter block (VPB)

Indicates the volume, or partition, that the file resides on

Pointer to section object pointers Indicates a root structure that describes a mapped file

Pointer to private cache map Identifies which parts of the file are cached by the cache manager and where they reside in the cache

EXPERIMENT: Viewing the File Object Data Structure EXPERIMENT: Viewing the File Object Data Structure

Opening a file object Opening a file object

EXPERIMENT: Viewing Device Handles EXPERIMENT: Viewing Device Handles

EXPERIMENT: Viewing Windows Device Name to Windows Device Name Mappings

EXPERIMENT: Viewing Windows Device Name to Windows Device Name Mappings

목차목차


Synchronous I/O and Asynchronous I/OSynchronous I/O and Asynchronous I/O

Fast I/O Fast I/O

bypass generating an IRP and instead go directly to the file system driver or cache manager to complete an I/O request.A driver registers its fast I/O entry points by entering them in a structure pointed to by the PFAST_IO_DISPATCH pointer in its driver object

EXPERIMENT: Looking at a Driver's Registered Fast I/O Routines EXPERIMENT: Looking at a Driver's Registered Fast I/O Routines

Mapped File I/O and File Caching Mapped File I/O and File Caching

the ability to view a file residing on disk as part of a process's virtual memory CreateFileMapping and Map- ViewOfFile functions File systems use the cache manager to map file data in virtual memory to provide better response time for I/O- bound programs

Data structures involved in a single-layered driver I/O request Data structures involved in a single-layered driver I/O request

EXPERIMENT: Looking at Driver Dispatch Routines EXPERIMENT: Looking at Driver Dispatch Routines

EXPERIMENT: Looking at a Thread's Outstanding IRPs EXPERIMENT: Looking at a Thread's Outstanding IRPs

Queuing and completing a synchronous request Queuing and completing a synchronous request

Servicing a device interrupt (phase 1) Servicing a device interrupt (phase 1)

Servicing a device interrupt (phase 2) Servicing a device interrupt (phase 2)

Completing an I/O request (phase 1) Completing an I/O request (phase 1)

Completing an I/O request (phase 2) Completing an I/O request (phase 2)

Synchronization Synchronization

The execution of a driver can be preempted by higher-priority threads and time-slice (or quantum) expiration or can be interrupted by interrupts On multiprocessor systems, Windows can run driver code simultaneously on more than one processorKeAcquireInterruptSpinLock

Queuing an asynchronous request to layered drivers Queuing an asynchronous request to layered drivers

EXPERIMENT: Viewing a Device Stack EXPERIMENT: Viewing a Device Stack

EXPERIMENT: Examining IRPs EXPERIMENT: Examining IRPs

Completing a layered I/O request Completing a layered I/O request

Queuing associated IRPs Queuing associated IRPs

Completing associated IRPs Completing associated IRPs

I/O Completion Ports I/O Completion Ports

Driver Verifier Driver Verifier

looking for a number of illegal operations—including calling kernel-memory pool functions at invalid IRQL, double-freeing memory, and requesting a zero-sized memory allocation

목차목차


FeaturesFeatures

automatically recognizes installed devices enumerating devices attached to the system during a boot and detecting the addition and removal of devices as the system executes Hardware resource allocation Loading appropriate drivers

If a suitable driver isn't installed, the kernel-mode PnP manager communicates with the user-mode PnP manager to install the device, possibly requesting the user's assistance in locating a suitable set of drivers

application and driver mechanisms for the detection of hardware configuration changes

Driver Support for Plug and Play Driver Support for Plug and Play

must implement Plug and Play dispatch routinea power management dispatch routine an add-device routine.

start-device command configure its device to use the specified resources

query- remove notification Applications typically register for notification on their handles, which they close during a query-remove notification the driver has a chance to deny the removal or to ensure that any pending I/O operations involving the device have completed and to begin rejecting further I/O requests aimed at the device

remove command

PC card remove/eject utility PC card remove/eject utility

PnP CommandsPnP Commands

query-stop command To reassign a device's resources, temporarily suspend further activity on the device

query-remove command completes pending I/O operations and won't initiate further I/O requests for the device that can't be aborted and subsequently restarted

stop command direct the driver to assign different resources to the device and once again send the driver a start-device command for the device

Device Plug and Play state transitions Device Plug and Play state transitions

The Start Value The Start Value

two main differences between explicit device driver loading and Windows service loading

Only device drivers can specify Start values of boot-start (0) or system-start (1) Device drivers can use the Group and Tag values to control the order of loading within a phase of the boot

Start value of 0 means that the operating system loader loads the driver Start value of 1 means that the I/O manager loads the driver after the executive subsystems have finished initializing

Guideline of Start ValueGuideline of Start Value

Non–Plug and Play drivers set their Start value to reflect the boot phase they want to load in Value 0:

Drivers, including both Plug and Play and non–Plug and Play drivers, that must be loaded by the boot loader during the system bootEx) system bus drivers and the boot file system driver

Value 1: A driver that isn't required for booting the system and that detects a device that a system bus driver can't enumerate Ex) serial port driver

Value 2:A non–Plug and Play driver or file system driver that doesn't have to be present

Value 3:Plug and Play drivers that aren't required to boot the systemEx) Network Adapter

Device Enumeration Device Enumeration

begins device enumeration with a virtual bus driver called Root HAL acts as a bus driver that enumerates devices directly attached to the motherboard HAL relies on the hardware description the Setup process recorded in the registry

Example device tree Example device tree

Device Manager showing the device tree Device Manager showing the device tree

the load and initialization order of drivers the load and initialization order of drivers 1. The I/O manager invokes the driver entry

routine of each boot-start driver. If a boot driver has child devices, the I/O manager enumerates those devices, reporting their presence to the PnP manager

2. After the boot-start drivers are initialized, the PnP manager walks the device tree, loading the drivers for devnodes that weren't loaded in step 1 and starting their devices

3. The PnP manager loads any drivers with a Start value of system-start that aren't yet loaded

4. The Service Control Manager loads drivers marked as auto-start

EXPERIMENT: Dumping the Device Tree EXPERIMENT: Dumping the Device Tree

Devnode Driver Loading Devnode Driver Loading

When a bus driver performs device enumeration, it reports device identifiers for the devices it detects back to the PnP manager device instance ID (DIID)

device IDvendor ID (VID) product ID (PID)

instance ID distinguish different instances of the same hardware

HKLM\SYSTEM\CurrentControlSet\Enum

ClassGUIDHKLM\ SYSTEM\CurrentControlSet\Control\Class Device’s devnode

Keyboard enumeration key Keyboard enumeration key

EXPERIMENT: Viewing Detailed Devnode Information in Device Manager

EXPERIMENT: Viewing Detailed Devnode Information in Device Manager

Keyboard class key Keyboard class key

Driver InstallationDriver Installation

Driver Installation Driver Installation

1. checks the registry for the presence of a corresponding function driver

2. The user-mode PnP manager first tries to perform an automatic install. require user interaction and the currently logged-on user has administrator privileges

3. execute the Hardware Installation Wizard (\Windows\System32\Newdev.dll). the user-mode PnP manager defers the installation until a privileged user logs on

4. Hardware Installation Wizard uses Setup and CfgMgr (Configuration Manager) API functions to locate INF files that correspond to drivers 1. require INF file (User select or \Windows\Driver Cache\i386\

Driver.cab )2. launch class or device co-installer DLLs that perform class or

device-specific installation steps 3. Check Driver-signing policy options

5. kernel-mode PnP manager starts the driver

EXPERIMENT: Looking at a Driver's INF File EXPERIMENT: Looking at a Driver's INF File

EXPERIMENT: Viewing Catalog Files EXPERIMENT: Viewing Catalog Files

목차목차


System Power-State Definitions System Power-State Definitions

Advanced Configuration and Power Interface (ACPI) specification

http://www.teleport.com/~acpi/spec.htm

State Power Consumption Software Resumption Hardware Latency

S0 (fully on) Maximum Not applicable None

S1 (sleeping) Less than S0, more than S2

System resumes where it left off (returns to S0) Less than 2 seconds

S2 (sleeping) Less than S1, more than S3

System resumes where it left off (returns to S0) 2 or more seconds

S3 (sleeping) Less than S2; processor is off

System resumes where it left off (returns to S0) Same as S2

S4 (hibernating) Trickle current to power button and wake circuitry

System restarts from saved hibernate file and resumes where it left off prior to hibernation (returns to S0)

Long and undefined

S5 (fully off) Trickle current to power button

System boot Long and undefined



System power-state transitions System power-state transitions

Example System-to-Device Power Mappings Example System-to-Device Power Mappings

System Power State Device Power State

S0 (fully on) D0 (fully on)

S1 (sleeping) D2

S2 (sleeping) D2

S3 (sleeping) D2

S4 (hibernating) D3 (fully off)

S5 (fully off) D3 (fully off)

EXPERIMENT: Viewing a Driver's Power Mappings EXPERIMENT: Viewing a Driver's Power Mappings

EXPERIMENT: Viewing the System Power Capabilities and Policy EXPERIMENT: Viewing the System Power Capabilities and Policy

Driver Control of Device Power Driver Control of Device Power

control the device power state of its devices PoRegisterDeviceForIdleDetection

registers the device with the power manage informs the power manager of the timeout values to use to detect a device as idle and of the device power state that the power manager should apply when it detects the device as being idle

PoSetDeviceBusy driver must inform the power manager, by calling the PoSetDeviceBusy function, whenever the device is active.

목차목차


ConclusionConclusion

Q&AQ&A

Documents

Ch. 9 I/O System