Device Management

Principle of I/O Hardware

I/O Devices

I/O devices can be roughly divided into two categories: block devices and character devices. The block devices stores information in fixed sized blocks, each one with its own address. Read or write is possible independent of other blocks. A character device delivers or acknowledges a stream of characters, without respect to any block structure. It is not addressable and does not have any seek operation. Printers, network interfaces, mice (for pointing), rats (for psychology lab tests), and most different devices that are not disk-like can be seen as character devices.

Device Controllers

I/O units typically consist of mechanical and electronic components. A controller is a collection of electronics that can operate a bus or a device. On PC, it often takes the form of printer circuit card that can be inserted into an expansion slot. A single controller can handle multiple devices; some devices have their own built-in controller. The controller has one or more registers for data and signals. The processor communicates with the controller by reading and writing bit patterns in these registers. When transferring a disk block of size 512 bytes, the block is first assembled bit by bit in a buffer inside the controller. After its checksum has been verified and the blocks are declared error free, it can be copied to the main memory.

Direct Memory Access (DMA)

DMA is a feature of modern computers that allow certain hardware subsystems within the computer to access system memory for reading or writing independently of the CPU. Without DMA, the CPU is fully occupied for the entire duration of read or write operation and is unavailable to perform other tasks. With the help of DMA, the CPU would initiate the transfer, do other operations while the transfer is in progress and receive an interrupt from the DMA controller once the operation has been done (Operating System Concepts, 2008). Many computers avoid burdening the CPU by offloading some of its work to special purpose processor called DMA controller. It consists of memory address register, a byte count register, and one or more control registers. More commonly, a single DMA controller is available for regulating transfer to multiple devices but some systems may have integrated with disk controllers.

How DMA works?

• The CPU programs the DMA controller by its registers so it knows what to transfer where. It also issues a command to disk controller telling it to read data from disk to its internal buffer and verify the checksum. When valid data are in disk’s controller buffer, DMA can start.
• The DMA controller initiates the transfer by issuing a read request over the bus to the disk controller.
• Data is transferred from disk controller to memory.
• When the transfer is completed, the disk controller sends an acknowledgment signal to DMA controller. The DMA controller then increments the memory address to use and decrements the byte count. This continues till the byte count is greater than 0.
• When the transfer is complete, the DMA controller interrupts the CPU.

Principle of I/O Software

Goals of I/O software

Device Independence

A program that reads a file as input should be able to read a file on a floppy disk, hard disk, CD or USB without having to modify for each type of file. The program should work on all kinds of devices.

Uniform Naming

Name of a file or a device should simply be a string or integer. It should not depend on the device. All files and devices should be addressed in the same way i.e. by pathname.

Error Handling

In general, errors should be handled by hardware. The device controller tries to correct the error by itself if it finds any error but if it can’t, the device drivers should handle it.

Synchronous v/s Asynchronous Transfer

Most I/O is asynchronous which means the CPU starts the transfer and does something else until the interrupt arrives. In synchronous, after a read system call, the program is automatically suspended until the data are available in the buffer.

Buffering

Usually, data coming from a device cannot be directly stored in its final destination. For example, when a packet comes off in a network, the OS does not know where to store it until it has stored the packet somewhere and examined it.

Interrupt Handlers

While programmed I/O is occasionally helpful, for most I/O, interrupts are an unpleasant truth and can't be avoided. They should be hidden away, deep in the bowels of the OS, so that as little of the OS as could reasonably be expected knows about them. The ideal approach to hide them is to have the driver starting an I/O operation block until the I/O has finished and the interrupt occurs. When the interrupt happens, the interrupt procedure does whatever it has to in order to handle the interrupt. Then it can unblock the driver that started it. The interrupt handler determines the cause of the interrupt and performs the necessary processing.

• Save any registers (including the PSW) that have not already been saved by the interrupt hardware.
• Set up a context for the interrupt service procedure. Doing this may involve setting up the TLB, MMU, and a page table.
• Set up a stack for the interrupt service procedure.
• Acknowledge the interrupt controller. If there is no centralized interrupt controller, re-enable interrupts.
• Copy the registers from where they were saved (possibly some stack) to the process table.
• Run the interrupt service procedure. It will extract information from the interrupting device controller’s registers.
• Choose which process to run next. If the interrupt has caused some high priority process that was blocked to become ready, it may be chosen to run now.
• Set up the MMU context for the process to run next. Some TLB set up may also be needed.
• Load the new process’ registers, including its PSW.
• Start running the new process. (Tanenbaum, 2013)

Device Drivers

Every I/O device attached to a PC needs some device-specific code for controlling it. This code called the device driver, is for the most part written by the device's producer and delivered alongside the device. Since each OS needs its own drivers, device makers commonly supply drivers for a few well known OS. Each device driver normally handles one device type, or at most one class of closely related devices. In some systems, the OS is a single binary program that contains all the drivers that it will need to be compiled into it.

Functions

• Accept R/W requests from the device independent software above it.
• Initialize the devices if necessary.
• Manage power requirement and log events.
• Check the status of the devices i.e. whether the device is in use or free.
• Decide which command to issue if there is a command queue.

Since the designers of every operating system know that pieces of code (drivers) written by outsiders will be installed in it, it needs to have an architecture that allows such installation. This means having a well-defined model of what a driver does and how it interacts with the rest of the operating system. Device drivers are normally positioned below the rest of the operating system, as illustrated in the figure below (Tanenbaum, 2013)

.

References

(2008). Retrieved from Operating System Concepts: http://os-concepts.blogspot.com/2008/07/direct-memory-access.html

Tanenbaum, A. S. (2013). Modern Operating Systems. Delhi: PHI Learning Private Limited.