Using Peripherals

Depends on	Device Drivers

There are different ways to use peripheral devices, depending on the trade-off between hardware and software on an individual system.

The simplest approach is to poll a device in software. A process checks the device status and ‘busy-waits’ until an operation can be carried out. This is an inefficient approach in most cases because a processor can be employed for considerable times simply waiting for some operation to complete.
- Analogy: you stand opening and closing your front door to see if a visitor has arrived.
Interrupt-driven I/O is more efficient. Here some status information is conveyed directly to a processor as a ‘demand’ for attention. When necessary, the interrupt will attract temporary processor attention to service the device.

A typical application may be to feed input (e.g. from a keyboard) into a FIFO buffer, acting as one end of a pipe-like communications channel.
- Analogy: you have a doorbell to attract attention whilst getting on with something else.
Interrupt-driven I/O is reasonable cheap (in resources) and is efficient providing the data rates are reasonably low. Due to the time required to service an interrupt it is not practical for high data rates because software will not ‘keep up’. High-speed I/O needs extra hardware support in the form of a DMA controller. This is pre-programmed with a (physical) memory address. Instead of being used as an interrupt, the peripheral status bit becomes a DMA request which causes the DMA controller to move the data without processor intervention; this is fast and energy-efficient. A typical DMA controller will move a block of data and interrupt the processor when that is complete. An example might be loading memory whilst paging where the page transfer can be left to occur in the background whilst the processor has time to context switch and run another process.
- Analogy: you have a servant who answers the doorbell for you.

As interfaces’ details vary between computers it is usual to interface to the hardware device via appropriate device driver software which can provide a standardised interface to applications code. (As far as possible) all devices look the same to the software. The driver code is part of the operating system because:

access to the peripheral device needs to be privileged, for security.
the device is a resource which (probably) needs to be granted to a single application for a given period. (Imagine the confusion if several processes could output to a printer at the same time!)

The MMU therefore will protect the page(s) containing peripheral devices; it will also need mark them with other properties, such as making it/them uncacheable.

Question: Why must an I/O device’s registers not be cached?

Max. number:

Max. distance:

Cacheability • Device Drivers • Direct Memory Access (DMA) • IO • Interprocess Communication • Interrupt Controller • Interrupt Service Routines (ISRs) • Interrupts • Libraries • Peripheral devices • Pipes • Queues • Queues Extra • Resources • Shell • Sockets • Spooling and Buffering • Starvation • Streams • System Calls • Thrashing • Timers • Using Peripherals • Virtualisation • Write Buffer

Articles on User

"Everything is a File" • Application Binary Interface (ABI) • Arrays • Boot • Buffer Overflow • Containers • Daemons • Disk Partition • Dynamic Memory Allocation • Emulator traps • Environment Variables • Errors • Exceptions • File Attributes • File Locking • File Permissions • Introduction to Operating Systems • Journalling File System • Links • Locks • Man(ual pages in Unix) • Memory Mapped Files • Monitoring • Network File System (NFS) • PATH • Pipes • Pointers • Relocatable Code • Reset • SETUID • Shell • Sockets • Spooling and Buffering • Streams • Structures • Superuser • System Calls • Unix Signals • User • Using Peripherals

Using Peripherals

Next