1. Chapter 13: I/O Systems
“The two main jobs of a computer are I/O and [CPU] processing. In many cases, the main job is I/O, and the [CPU] processing is merely incidental.” (p. 555)
“I/O is a major factor in system performance. It places heavy demands on the CPU to execute device-driver code and to schedule processes fairly and efficiently as they block and unblock” (p. 582)
“typically, about 70 percent of [an] operating system consists of device drivers” (p. 44, Tanenbaum et al., 2006; Can We Make Operating Systems Reliable and Secure)
It seems curious I/O is left until relatively late in the textbook
Historically, why did adding USB devices require changes to the Linux kernel and not just the addition of device drivers?

2. Overview Computer system architecture I/O Device Control
Accessing devices
Polling & interrupts
Device driver
Blocking, non-blocking, and asynchronous I/O

3. Figure 13.5
Bus: set of wires and a common protocol for communication with devices
Controller: electronics for managing an individual device, port, or a bus
Figure 13.1

4. I/O Device Control
Devices controlled via special registers of a device controller
CPU needs to control devices
Read or write control signals or data in special registers of a device controller
General interfaces
Port I/O: Special I/O machine instructions that trigger the bus to select the proper I/O port & move the data into or out of a device register
E.g., IN, INS, OUT, OUTS on numerous Intel architectures
Memory mapped I/O: The I/O registers of the device become part of the linear memory space of the “RAM” of the computer; standard memory load and store machine instructions are used
E.g., a serial port might use port I/O, while a graphics controller could have a memory-mapped image of the computer screen

5. Example I/O Port Instructions on Intel 64 & IA-32 (See next page)
2nd link is the instruction set architecture

6. Intel 64 & IA-32

7. General Methods for Accessing Devices
Two general methods by which devices can be accessed
Each of these methods can be used with either ports or memory-mapped I/O
Polling
A busy wait, repeatedly checking a device for some change in status
Interrupts
Using interrupt line of CPU to provide service to devices

8. Polling Also called programmed I/O
CPU is used (e.g., by a device driver), in a program code loop, to continuously check a device to see if it is ready to accept data or commands, or produce output
Continuous polling
In some cases, a process periodically checks a device, and then blocks until next period elapsed
Periodic polling
E.g., a USB mouse might be periodically polled for data at 100 Hz rate
Loop (until device ready)
Check device
End-loop

9. Issues with Continuous Polling
CPU is tied up in communication with device until I/O operation is done
No other work can be accomplished by CPU
Typically one CPU in system, but many I/O devices
May be useful if controller and device are fast
Programmed I/O can be more efficient than interrupt-driven I/O, if the number of cycles spent busy-waiting is not excessive
If polling interleaved with other processing
Device may be idle because we don’t supply it with information or a new request
Device might have a fixed length buffer, and we may get buffer overrun conditions, resulting in data loss

10. Hardware Interrupts
I/O via software continuous polling can be inefficient
CPU may spend too much time waiting for devices
I.e., amount of time between I/O operations may be large
Only one CPU; continuous polling may tie up this resource
Often better to design differently
Handle I/O as different type of event
No longer have CPU actively wait until device is ready for next operation
Instead, have the device send an asynchronous signal-- an interrupt when it is ready
CPU has wire called an interrupt request line
I/O controller sets the interrupt request line to 1
CPU, as part of instruction processing cycle, automatically checks interrupt request line
If it is set to 1, this generates a hardware interrupt

11. Figure 13.3 Interrupt-driven I/O cycle
The “…” at the bottom indicates that there may be a significant interval of time until next device driver usage. …

12. Dispatch of Interrupt Handlers
Interrupt vector table has a small collection of addresses for particular interrupt handling routines
If more devices than interrupt vector addresses, interrupts are chained & short sequential search is done; interrupt handlers called in sequence until one can handle interrupt
Figure 13.4: Pentium Processor Event-Vector Table

13. Other Interrupt Features
Interrupts can have different priorities
A higher priority interrupt can interrupt the handler of a lower priority interrupt (but not vice versa)
Maskable vs. nonmaskable interrupts
Normal I/O uses maskable interrupts that can be turned off (e.g., when kernel executes a critical section)
Fatal error conditions may use a nonmaskable interrupt to make sure interrupt gets through (e.g., see Fig. 13.4)

14. Device Drivers - 1 Generally handle device access details
E.g., program devices to initiate I/O operations and provide interrupt handlers
Present a uniform device-access interface to the I/O subsystem
Standard device driver interfaces are specified by the particular operating system
Figure 13.6: A Kernel I/O Structure

15. Device Drivers - 2
Internally, device drivers written specifically for a particular device and a particular O/S, but export a standard interface
To add a new device to a system, two basic strategies
Design a new device to be compatible with an existing controller interface-- can use an existing device driver
Write a new device driver to interface the new device hardware to popular operating system
Some new devices classes may require more changes
e.g., When USB devices added to Linux, this resulted in a stack of new modules, not just additions of new device drivers

16. Blocking vs. Nonblocking I/O
Blocking I/O (a.k.a., synchronous I/O)
Process suspended for duration of I/O operation
I.e., Process enters a waiting queue
Nonblocking I/O
Does not cause a process to enter a waiting queue
Returns immediately, with status information such as the number of bytes of data transferred
I/O processing (due to a non-blocking I/O request) does not continue after request
Asynchronous I/O
Similar to nonblocking I/O, but an asynchronous call not only returns immediately, but has I/O processing continue after call
Communication with process about completion of I/O can occur via a variable, callback, or signal, or polling
Put this earlier in presentation, perhaps at very start