I/O Structure

• Storage is only one of many types of I/O devices within a computer. A large portion of OS code is dedicated to managing I/O, both because of its importance to the reliability and performance of a system and because of the varying nature of the devices.
• A source of cheaper-per-byte and non-volatile storage is provided by magnetic disk. However, the computer does not have direct random access to any byte at any time on the disk - the magnetic discs in the drive are rotating and magnetic heads move in and out in order to access any part of the surface area on the disc that holds data. This means access usually involves a disc rotation delay and also a head positioning delay (see Fig. 14left).

  Figure 14: Left: Structure of a disk drive. Right: The steps in starting an I/O device.

  Figure 15: Upper: Top-level Components. Lower: The structure of a large Pentium system.

  

  
• A general-purpose computer system consists of CPUs and multiple device controllers that are connected through a common bus (see Fig. 15).
  • Each device controller is in charge of a specific type of device. Depending on the controller, there may be more than one attached device.
  • The device controller is responsible for moving the data between the peripheral devices that it controls and its local buffer storage (see Fig. 14right).
  • Typically, OSs have a device driver for each device controller. Software that communicates with controller is called device driver. This device driver understands the device controller and presents a uniform interface to the device to the rest of the OS. Most drivers run in kernel mode. To put new driver into kernel, system may have to be relinked, or be rebooted, or dynamically load new driver.
  • A system bus would link the CPU and memory. This structure would involve a pathway along which data could travel (usually 32-bits side-by-side i.e. in bit-wise parallel).
• To start an I/O operation;
  • The device driver loads the appropriate registers within the device controller.
  • The device controller, in turn, examines the contents of these registers to determine what action to take (such as "read a character from the keyboard").
  • The controller starts the transfer of data from the device to its local buffer. Once the transfer of data is complete, the device controller informs the device driver via an interrupt that it has finished its operation.
  • The device driver then returns control to the OS, possibly returning the data or a pointer to the data if the operation was a read.
• Interrupts normal sequence of execution. I/O requests can be handled synchronously or asynchronously.
  • In a synchronous system, a program makes the appropriate OS call, as the CPU is now executing OS code, the original program's execution is halted i.e. it waits.
  • In an asynchronous system, a program makes its request via the OS call, then its execution resumes, it will most likely not have had its request serviced yet! The advantage of having an asynchronous mechanism available is that the programmer is free to organize other CPU activity while the I/O request is handled.
• This form of interrupt-driven I/O is fine for moving small amounts of data but can produce high overhead when used for bulk data movement such as disk I/O. CPU much faster than I/O devices, hence waiting for I/O operation to finish is inefficient.
• To solve this problem, direct memory access (DMA) is used. After setting up buffers, pointers, and counters for the I/O device, the device controller transfers an entire block of data directly to or from its own buffer storage to memory, with no intervention by the CPU.
• Only one interrupt is generated per block, to tell the device driver that the operation has completed, rather than the one interrupt per byte generated for low-speed devices.
• While the device controller is performing these operations, the CPU is available to accomplish other work.