5.1 Input - output management

Input-output (I/O) management is the part of the operating system that controls every transfer of data between the processor, main memory and peripheral devices such as keyboards, disks, printers, network cards and scanners. Peripheral devices are slower than the CPU, come from many manufacturers and behave differently, so the operating system hides these differences behind a uniform interface and decides when and how each transfer takes place.

Example: at a SACCO banking hall in Murang'a, the teller's PC reads a member card, prints a receipt and writes the transaction to disk; the I/O manager coordinates all three devices so that the teller sees one smooth operation.

5.1.1 Definition

I/O management is the set of operating system functions, data structures and driver software that receives requests for input or output from processes, schedules them, passes them to the correct device, monitors their progress and reports the result back to the requesting process. It sits between user programs and the hardware controllers.

• I/O device: any hardware unit that supplies data to the computer or receives data from it, for example a mouse, monitor, hard disk or network adapter.
• Device controller: the electronic circuit on the device or motherboard that understands the device's signals and has its own registers and buffer.
• Device driver: operating system software that knows how to talk to one type of controller and translates general commands such as "read block 200" into controller commands.
• I/O request: a call made by a process, normally through a system call such as read() or write(), asking for data to be moved.

5.1.2 Objectives of I/O management

The I/O subsystem is designed to meet a set of goals that keep the whole computer efficient and reliable.

• Efficiency: keep the CPU and the devices busy at the same time so that slow devices do not hold up computation, for example by overlapping disk reads with processing.
• Device independence: let programs use the same commands for different devices, so a program can save to a hard disk, flash drive or network share without being rewritten.
• Uniform naming: give devices and files simple names such as C:\ or /dev/sda that do not depend on the hardware model.
• Error handling: detect and, where possible, correct errors close to the hardware, for example by retrying a failed disk read before reporting failure to the user.
• Synchronous and asynchronous transfers: support both blocking calls, where a process waits, and interrupt-driven transfers, where the process continues and is notified later.
• Sharing and protection: allow shareable devices such as disks to be used by many processes while giving dedicated devices such as printers to one job at a time, and preventing unauthorised access.
• Buffering: smooth out differences in speed and data unit size between devices and memory.

5.1.3 I/O hardware

I/O hardware consists of the physical parts that move data between the computer and the outside world. Knowing these parts helps a technician diagnose faults and choose drivers.

Ways the CPU talks to controllers

• Port-mapped I/O: the CPU uses special instructions (IN and OUT on x86) to read and write controller registers that have their own address space.
• Memory-mapped I/O: controller registers appear as ordinary memory addresses, so normal load and store instructions control the device; graphics cards use this widely.
• Direct Memory Access (DMA): the CPU programs the DMA controller with a source, destination and byte count, then carries on with other work; the DMA controller raises an interrupt when the block transfer is complete.

Types of devices

• Block devices: store data in fixed-size blocks that can be addressed individually, for example hard disks and SSDs.
• Character devices: deliver or accept a stream of characters with no addressing, for example keyboards, mice and serial ports.
• Network devices: send and receive packets through a socket interface.

5.1.4 I/O software

I/O software is organised in layers. Each layer uses the services of the one below it and offers a simpler service to the one above it.

1. User-level I/O software: library routines such as printf() in C and spooling programs that format data and make system calls.
2. Device-independent operating system software: provides uniform naming, buffering, error reporting, allocation of dedicated devices and a standard block size.
3. Device drivers: device-specific code that issues commands to the controller, checks status and handles device errors; drivers are supplied by the hardware vendor or by the operating system.
4. Interrupt handlers: short routines that run when a device signals completion; they save the CPU state, acknowledge the interrupt and wake the waiting driver or process.
5. Hardware: the controllers and devices that carry out the physical transfer.

When a user saves a document, the request passes down these layers: the word processor calls write(), the file system finds the disk blocks, the disk driver programs the controller, the controller performs the transfer and raises an interrupt, and the interrupt handler tells the driver that the work is done.

5.1.5 Polling Vs Interrupt-driven I/O

The CPU needs a way to know when a device has finished an operation or has data ready. The two basic methods are polling and interrupts.

Polling

In polling (also called programmed I/O or busy waiting), the CPU repeatedly reads the device's status register in a loop until the busy bit clears, then moves the next byte. Polling is simple and has very low delay for fast devices, but it wastes processor time when the device is slow, because the CPU does nothing useful while waiting.

Interrupt-driven I/O

In interrupt-driven I/O, the CPU starts the operation and then switches to another process. When the device finishes, its controller sends an interrupt signal; the CPU suspends the current work, runs the interrupt service routine for that device and then resumes. This frees the CPU for useful work but each interrupt costs time for saving and restoring state.

Modern systems combine both: a network card under heavy load switches from interrupts to polling (as in the Linux NAPI method) to avoid an interrupt storm, then returns to interrupts when traffic drops.