I/O Control in Operating Systems
The I/O bus allows communications with hardware devices; each device on the bus has an address, and is instructed when to transmit and receive data. A device controller sits between the storage device and the bus, to provide a generic interface for the hardware to connect to. Software known as device drivers will allow the operating system to manage the actions which must take place to correctly communicate with different devices.
I/O devices have a number of characteristics which affect the way they have to be handled by the operating system. These include:
- The method of data transfer
- How the device is accessed
- How data transfers are scheduled, to avoid conflicts
- Whether or not different processes can share the device
- The direction of data from the device (In/Out or Both)
- The speed of the device, which in turn depends on the following factors:
- Seek Time (time taken for the device to find the required data/process)
- Latency (time taken to prepare for an action)
- Transfer Time (time taken to move data from place to place)
- Delay (time taken between operations)
After they have been instructed to perform an operation, there are two different ways in which the result of an operation in a device can be retrieved by the operating system - it can either poll the device (regularly checking the status register of a device until it reports that its operation is finished) or wait for an interrupt (the device controller registers itself with the kernel of the operating system, and is then able to cause a hardware interrupt when the device needs attention).
A device's data can be accessed in two different ways, either it can be accessed through the interrupt method previously mentioned, or by a system known as Direct Memory Access (DMA). DMA allows devices to transfer data between themselves and main memory without the intervention of the CPU. It requires there to be a DMA controller on the bus, but it can dramatically improve transfer speeds and allow high-speed data access.
Interrupt Driven I/O
Under this system, the device controller uses an application program called a 'trap' which causes the to act as if a hardware interrupt had occurred. This allows the operating system to launch a privileged-mode instruction as defined in a trap-table stored in the kernel. The application cause the instructions to be launched in privileged mode so they are able to interact with the CPU at the highest level - with access to all necessary hardware devices.
When an interrupt occurs, the following steps are taken by the Operating System:
- The interrupt mechanism is launched. This saves the program counter and other registers then enters the first-line interrupt handler (FLIH)
- The first-line interrupt handler then kicks it, this saves any program registers then identified the interrupt and the relevant service routine for it.
- The service routine for the interrupt is then launched, this may alter the process status in an attempt to rectify whatever problem has occurred.
- The dispatcher is then run, it will determine whether the process should be switched or not, if so a new process will be run and the volatile memory from the interrupted method stored - or alternatively the interrupted process will be resumed and the registers restored.
References:
- Janet Lavery - Durham University Computer Systems, Operating Systems Lecture 1, 2007
- A2 Computing Revision - Paul Nicholls - http://resources.r9paul.org/ASA2/Computing/A2ComputingRevision.pdf
- Polling and Interrupts - David Rusling - http://sunsite.nus.sg/LDP/LDP/tlk/node86.html
- Device Management CT213 - geminga.nuigalway.ie/~p_bigioi/ct213/CT213_DeviceManagement.ppt