Operating Systems 1 (11/12) - Input / Output
5 likes5,845 views
The document provides an overview of input/output (I/O) devices and their functionality within operating systems, detailing different types of I/O devices, such as block and character devices. It discusses mechanisms for I/O operations, including programmed I/O, interrupt-driven I/O, and direct memory access (DMA), as well as the role of device drivers and the buffering process. Additionally, the document covers design objectives for I/O systems and specifics of the Windows I/O architecture, including the structure and function of the I/O manager and interrupt handling mechanisms.
Operating Systems 1 (11/12) - Input / Output
- 1. I/O Beuth Hochschule Summer Term 2014 ! Pictures (C) W. Stallings, if not stated otherwise ! Additional source: Daniel P. Bovet & Marco Cesati. Understanding the Linux Kernel. 3rd Edition. O‘Reilly ! ! !
- 2. Operating Systems I PT/FF 14 Input / Output Devices • Hardware devices engaged in I/O can be categorized into: • Responsible for interaction with the user • Printers, terminals, video display, keyboard, mouse • Provisioning of system-local hardware functionality • Disk drives, USB keys, sensors, controllers • Provisioning of communication support • Modems, WLAN stick, network card • Devices differ according to multiple factors • Data transfer rates, complexity of control, data encoding, error conditions, ... • I/O devices either operate as block device (fixed-size data blocks) or character / stream device (stream of bytes) 2
- 3. Operating Systems I PT/FF 14 I/O Functionality • I/O functionality in an operating system can take place as: • Programmed I/O with polling • Process issues I/O command indirectly through the operating system • Busy waits for completion • Interrupt-driven I/O • Process issues I/O command indirectly through the operating system • Operating system blocks the process until an interrupt signals I/O completion • With non-blocking I/O, the process continues to work instead of being blocked • In both cases, the processor must fetch I/O read results from the device • Alternative: Direct Memory Access (DMA) 3
- 4. Operating Systems I PT/FF 14 I/O Hardware - Single Bus 4 (C) Russinovich et al.
- 5. Operating Systems I PT/FF 14 I/O Hardware - Multiple Busses 5 (C) Russinovich et al.
- 6. Operating Systems I PT/FF 14 Direct Memory Access (DMA) • Special hardware unit realizes the data transfer between device and main memory 6
- 7. Operating Systems I PT/FF 14 Device Drivers • Lowest level of software to interact with I/O hardware • Contains all device-dependent code for one type of hardware unit • Direct communication with the device hardware • Writes control registers, accesses hardware-mapped memory regions • Starting and completion of I/O operations • Loaded drivers become part of the running operating system image • User mode applications deal with logical I/O • Processes are enabled to access data records in files • Driver may block after issuing a request, un-blocked by device interrupt 7
- 8. Operating Systems I PT/FF 14 Flow of a Blocking I/O Request 1. Thread issues blocking read() system call 2. Kernel checks parameters, may already return buffered data and finish 3. Thread is suspended if physical I/O required, added to wait queue for device 4. I/O request is scheduled 5. Device driver allocates kernel buffer and sends command to the hardware controller 6. Device controller operates the hardware to perform data transfer 7. Driver may poll for status and data, or set up DMA that will generate interrupt 8. Interrupt occurs, handler implementation from the driver stores the data 9. Kernel transfers data to user space and makes thread ready again 10. Thread resumes execution at completion of read() call 8
- 9. Operating Systems I PT/FF 14 Design Objectives • Design objectives for the I/O mechanism in operating systems • Generality • Handle all devices in a uniform manner, both for kernel and user mode • Hierarchical approach for device management to reflect bus topology • Efficiency • I/O operations nearly always are the main bottleneck in application performance • Most I/O devices are extremely slow compared with main memory and processor • Operating system must take care of disk I/O coordination and performance 9
- 10. Operating Systems I PT/FF 14 Layers of the I/O System • Device-independent software layer combines common management tasks • Uniform interfacing for device interaction (e.g. read / write / create) • Device naming • Device protection • Buffering • Storage allocation on block devices • Allocation and releasing • Error reporting 10 User process Device-independent software layer Device driver layer Interrupt handlers Hardware
- 11. Operating Systems I PT/FF 14 Buffering • Typical optimization is buffering of I/O requests • Perform input transfers in advance of requests being made • Perform output transfers delayed, after the request is made 11
- 12. Operating Systems I PT/FF 14 Buffering • No buffer - Operating system directly accesses the device • Single buffer - Operating system assigns buffer in main memory for I/O request • For block-oriented devices, read-ahead may manage to prepare blocks in memory that are fetched later by the process • For stream-oriented devices, read-ahead is based on the notion of text lines (terminals) or bytes (terminals, video stream) • Swapping logic of the operating system is affected • Double buffer / buffer swapping - Process can transfer data from / to one buffer while the operating system empties or fills the other buffer • Circular buffer - Two or more buffers are used in a circular fashion • Buffering smoothes out peaks in I/O demand, less advantage under heavy load 12
- 13. Operating Systems I PT/FF 14 Windows • I/O system design goals • Fast I/O processing on single / multiprocessor systems • Protection for shareable resources using Windows security mechanisms • Meet requirements dictated by different subsystems • Provide common services for device drivers • Ease device driver development, support for high-level languages • Dynamic addition/removal of device drivers • Support multiple file systems (FAT, CDFS, UDF, NTFS) • Provide mapped file I/O capabilities • Instrumentation support and diagnosability 13
- 14. Operating Systems I PT/FF 14 Windows 14 (C) Russinovich et al.
- 15. Operating Systems I PT/FF 14 Windows - I/O Architecture • I/O Manager • Connects applications and components to virtual, logical, and physical devices • Windows APIs: ReadFile, WriteFile, CreateFile, CloseFile, DeviceIoControl • Defines the infrastructure that supports device drivers • Manages buffers for I/O requests • Provides time-out support for drivers • Knows which installable file systems are loaded • Provides flexible I/O services for environment subsystems • Framework for delivery of I/O request packets (IRPs) 15
- 16. Operating Systems I PT/FF 14 Windows - I/O Architecture • The hardware abstraction layer (HAL) insulates drivers from the specifics of processor and interrupt controller • Bus driver for all the devices on the computer's motherboard that aren't controlled by other drivers • By programming against the HAL, drivers are source-level compatible across different CPU and mainboard architectures • PnP manager handles driver loading and starting • Performs resource arbitration • Relies on the I/O Manager to manage drivers and send PnP-related commands • Power manager controls the power states • Relies on the I/O Manager to ask drivers if they can change power state 16
- 17. Operating Systems I PT/FF 14 Driver Layering • Windows drivers can be stacked to add functionality • Only the lowest layer talks to the hardware • Filter drivers attach their devices to other devices • See‘s all requests first an can manipulate them • Examples: File replication, file encryption, shadow copies, licensing, virus scanner 17
- 18. Operating Systems I PT/FF 14 Windows - IRPs • I/O manager creates an IRP for each I/O operation and passes it to correct drivers • Deletes IRP when I/O operation is complete • Device drivers • Receive IRP routed to them by the I/O manager and performs the operation • Inform the I/O manager when those commands complete by passing back the IRP • Often use the I/O manager to forward IRPs to other device drivers • Fast I/O • Bypass generation of IRPs, go directly to file system driver or cache manager • Scatter/Gather I/O • Read/write multiple buffers with a single system call 18
- 19. Operating Systems I PT/FF 14 Windows - Interrupt Dispatching 19 (C) Russinovich et al.
- 20. Operating Systems I PT/FF 14 Windows - Interrupt Dispatching • IRQL is the state of a processor in the system • Servicing an interrupt raises the processor IRQL to that interrupt‘s IRQL • This masks subsequent interrupts with an equal or lower IRQL • User mode applications are limited to IRQL 0 • No wait operations or page faults for IRQL >= 2 • After ISR execution, IRQL is lowered to initial level 20 Passive/Low APC Dispatch/DPC Device 1 . . . Profile & Synch (Srv 2003) Clock Interprocessor Interrupt Power fail High Normal thread execution Hardware interrupts Deferrable software interrupts 0 1 2 30 29 28 31
- 21. Operating Systems I PT/FF 14 Windows - IRQLs • High - Used when halting the system (via KeBugCheck()) • Power fail - Originated in the NT design document, but has never been used • Inter-processor interrupt - used to request action from other processor (dispatching a thread, updating a processors TLB, system shutdown, system crash) • Clock - Used to update system‘s clock, allocation of CPU time to threads • Profile - Used for kernel profiling (see Kernel profiler – Kernprof.exe, Res Kit) • Device - Used to prioritize device interrupts • DPC/dispatch and APC - Software interrupts that kernel and device drivers generate • Passive - No interrupt level at all, 0 normal thread execution 21 Passive/Low APC Dispatch/DPC Device 1 . . . Profile & Synch (Srv 2003) Clock Interprocessor Interrupt Power fail High Normal thread execution Hardware interrupts Deferrable software interrupts 0 1 2 30 29 28 31