1. Ch. 9 I/O System 발표자 : 서우석 발표일 : 2006 년 11 월 6 일

2. 목차 I/O System Components Device Drivers I/O Processing The Plug and Play (PnP) Manager The Power Manager Conclusion

3. 목차 I/O System Components Device Drivers I/O Processing The Plug and Play (PnP) Manager The Power Manager Conclusion

4. Design Goal Provide an abstraction of devices to apps. Features High performance asynchronous packet-based I/O Services support High-Level language and different machine architecture Layering 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

5. I/O System Components

6. I/O Manager The Core of the I/O System I/O System is packet driven Presented by an I/O Request Packet (IRP) Create  Passing  (Forwarding  ) Disposing Supply common code Individual drivers become simpler and more compact. Other features Manages buffers for I/O requests Provides timeout support Records installable file systems Common routines Asynchronous I/O

7. Typical 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/O open, close, read, write functions

8. The flow of a typical I/O request

9. 목차 I/O System Components Device Drivers I/O Processing The Plug and Play (PnP) Manager The Power Manager Conclusion

10. Types of Device Drivers user-mode drivers Virtual device drivers to emulate 16-bit MS-DOS app Printer drivers kernel-mode drivers File system drivers Plug and Play drivers Non–Plug and Play drivers ex) network API and protocol drivers

11. WDM Drivers support for Windows power management, Plug and Play, and WMI Types of WDM drivers Bus drivers manage a logical or physical bus ex) PCMCIA, PCI, USB, IEEE 1394, and ISA detecting 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

12. Layered Drivers Class drivers implement the I/O processing for a particular class of devices, such as disk, tape, or CD-ROM where the hardware interfaces have been standardized and so one driver can serve devices from a wide variety of manufacturers Port drivers implement the processing of an I/O request specific to a type of I/O port, such as SCSI implemented as kernel-mode libraries of functions Miniport drivers map a generic I/O request to a type of port into an adapter type, such as a specific SCSI adapter

13. Example: How device drivers work

14. Example: Adding a layered driver

15. EXPERIMENT: Viewing the Loaded Driver List

16. Key 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

17. Other routines One or more I/O completion routines notify 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

18. Driver Objects and Device Objects driver object represents 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

19. Location 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

20. EXPERIMENT: Looking at the \Device Directory

21. The driver object

22. EXPERIMENT: Displaying Driver and Device Objects

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

24. File Object Attributes FILE_OBJECT in Ntddk.h AttributePurpose FilenameIdentifies the physical file that the file object refers to Current byte offsetIdentifies the current location in the file (valid only for synchronous I/O) Share modesIndicate whether other callers can open the file for read, write, or delete operations while the current caller is using it Open mode flagsIndicate whether I/O will be synchronous or asynchronous, cached or noncached, sequential or random, and so on Pointer to device objectIndicates 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 pointersIndicates a root structure that describes a mapped file Pointer to private cache mapIdentifies which parts of the file are cached by the cache manager and where they reside in the cache

25. EXPERIMENT: Viewing the File Object Data Structure

26. Opening a file object

27. EXPERIMENT: Viewing Device Handles

28. EXPERIMENT: Viewing Windows Device Name to Windows Device Name Mappings

29. 목차 I/O System Components Device Drivers I/O Processing The Plug and Play (PnP) Manager The Power Manager Conclusion

30. Synchronous I/O and Asynchronous I/O

31. 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

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

33. 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

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

35. EXPERIMENT: Looking at Driver Dispatch Routines

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

37. Queuing and completing a synchronous request

38. Servicing a device interrupt (phase 1)

39. Servicing a device interrupt (phase 2)

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

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

42. 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 processor KeAcquireInterruptSpinLock

43. Queuing an asynchronous request to layered drivers

44. EXPERIMENT: Viewing a Device Stack

45. EXPERIMENT: Examining IRPs

46. Completing a layered I/O request

47. Queuing associated IRPs

48. Completing associated IRPs

49. I/O Completion Ports

50. 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

51. 목차 I/O System Components Device Drivers I/O Processing The Plug and Play (PnP) Manager The Power Manager Conclusion

52. Features 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

53. Driver Support for Plug and Play must implement Plug and Play dispatch routine a 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

54. PC card remove/eject utility

55. PnP 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

56. Device Plug and Play state transitions

57. 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

58. Guideline 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 boot Ex) 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 system Ex) Network Adapter

59. 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

60. Example device tree

61. Device Manager showing the device tree

62. 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

63. EXPERIMENT: Dumping the Device Tree

64. 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 ID vendor ID (VID) product ID (PID) instance ID distinguish different instances of the same hardware HKLM\SYSTEM\CurrentControlSet\Enum ClassGUID HKLM\ SYSTEM\CurrentControlSet\Control\Class Device’s devnode

65. Keyboard enumeration key

66. EXPERIMENT: Viewing Detailed Devnode Information in Device Manager

67. Keyboard class key

68. Driver Installation

69. 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

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

71. EXPERIMENT: Viewing Catalog Files

72. 목차 I/O System Components Device Drivers I/O Processing The Plug and Play (PnP) Manager The Power Manager Conclusion

73. System Power-State Definitions Advanced Configuration and Power Interface (ACPI) specification http://www.teleport.com/~acpi/ spec.htm StatePower ConsumptionSoftware ResumptionHardware Latency S0 (fully on)MaximumNot applicableNone 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 bootLong and undefined

74. System power-state transitions

75. Example System-to-Device Power Mappings System Power StateDevice 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)

76. EXPERIMENT: Viewing a Driver's Power Mappings

77. EXPERIMENT: Viewing the System Power Capabilities and Policy

78. 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.

79. 목차 I/O System Components Device Drivers I/O Processing The Plug and Play (PnP) Manager The Power Manager Conclusion

81. Q&A