8 Input and Output Management

The operating system’s role

Input/output (I/O) management coordinates communication between programs and hardware, including keyboards, disks, displays, network adapters, and sensors. Applications usually request I/O through operating-system services rather than controlling hardware directly. The operating system checks and routes requests, manages buffers and access permissions, and reports results to the requesting program.

How requests reach devices

A typical I/O request passes through several layers: an application issues a read or write, the operating system’s I/O subsystem prepares and routes the request, a device driver translates it into device-specific commands, and the device performs the operation. When the operation finishes, the operating system makes the result available to the program.

This layering gives programs a consistent way to use different devices while allowing drivers to handle hardware-specific details. The operating system can load and connect an appropriate driver when it detects a device. Some systems also support asynchronous I/O, which lets a program continue other work while an operation is in progress.

Drivers and hardware interfaces

A device driver translates general requests, such as a request to read bytes, into commands that a particular device understands. It also handles device-specific status and errors. Drivers may be layered, with one passing a request to another before it reaches the hardware.

To communicate with hardware, a driver may access device registers, which are small control and status locations used to issue commands or check device state. Some devices expose registers through memory-mapped I/O (MMIO), where a region of address space is used to access the device. Others use a separate I/O port space. Drivers use operating-system-provided access methods so hardware access is handled appropriately for the system’s architecture.

Buffers, transfers, and completion

A buffer is temporary memory that holds data while it moves between a program and a device. Buffers help accommodate differences in speed and transfer size: for example, a keyboard produces input gradually, while a program may process it in larger chunks. Depending on the type of I/O and the system’s rules, the operating system may also use caching to avoid repeating some device accesses.

For large transfers, a device may use direct memory access (DMA) to transfer data between the device and main memory without requiring the CPU to copy each byte. The operating system and driver arrange the transfer and handle its completion; the exact mechanisms depend on the hardware and operating system.

After an operation completes, the driver and operating system record its status and make any returned data available. Depending on whether the operation is synchronous or asynchronous, the requesting program may be notified or allowed to continue. Errors, such as an unavailable device or failed transfer, are also reported through the operating system’s I/O interfaces.

Polling and interrupts

The operating system or driver needs to know when a device is ready or has completed work. Two common approaches are polling and interrupts.

• Polling: The CPU repeatedly checks a device’s status. This is straightforward and can be useful when checking frequently, but repeated checks consume processing time even when the device has nothing to report.

• Interrupts: A device signals the processor when it needs attention. The processor temporarily pauses its current work, runs an interrupt handler, and then resumes other work. Interrupts avoid constant checking, though servicing them has overhead.

When an interrupt occurs, the operating system identifies the relevant handler, often with help from the device driver. The handler should do the time-sensitive work needed to acknowledge or identify the event. Longer processing can be deferred to a later context to keep the immediate response short. If devices share an interrupt, a handler may need to check whether its own device caused it.

Example: reading a file

When a program requests data from a file, it asks the operating system to read the file rather than operating the storage device directly. The file system identifies where the data is stored, and the I/O subsystem passes the necessary request to the storage driver. The driver instructs the device to retrieve the data, possibly using DMA. The device may signal completion with an interrupt, after which the operating system makes the data available to the program. File systems, drivers, buffers, and interrupt handling cooperate in this process.