A short introduction into the principles of input / output and device management in modern operating systems.

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