1.7 I/o devices and file systems  (Page 2/9)

Direct memory access (dma)

In simple systems, the CPU must move each data byte to or from the bus using a LOAD or STORE instruction, as if the data were beingmoved to memory. This quickly uses up much of the CPU's computational power. In order to allow systems to support high I/O utilization while the CPU is gettinguseful work done on the users' behalf, devices are allowed to directly access memory. This direct access of memory by devices (or controllers is called DirectMemory Access, commonly abbreviated DMA).

The CPU is still responsible for scheduling the memory accesses made by DMA devices, but once the program has been established,the CPU has no further involvement until the transfer is complete. Typically DMA devices will issue interrupts on I/O completion.

Because this memory is not being manipulated by the CPU, and therefore addresses may not pass through an MMU, DMA devices oftenconfuse or are confused by virtual memory. It is important to guarantee thatmemory intended for use by a DMA device is not manipulated by the paging system while the I/O is being performed. Such pages are usually frozen (or pinned) toavoid changes.

In some sense DMA is simply an intermediate step to general purpose programmability on devices and device controllers. Several suchsmart controllers exist, with features ranging from bit swapping, to digital signal processing, checksum calculations, encryption and compression and generalpurpose processors. Dealing with that programmability requires synchronization and care. Moreover, in order for code to be portable, writing an interface tosuch smart peripherals is often a delicate balancing act between making features available and making the device unrecognizable.

I/o software

The I/O software of the OS has several goals:

• Device Independence: All peripherals performing the same function should have the same interface. All disks should present logical blocks. Allnetwork adapters should accept packets. The protection of devices should be managed consistently. For example devices should all be accessible bycapability, or all by the file system. In practice this is mitigated by the need to expose some features of the hardware.
• Uniform Naming: The OS needs to have a way to describe the various devices in the system so that it can administer them. Again the naming systemshould be as flexible as possible. Systems also have to deal with devices joining or leaving the name space (PCMCIA cards).
• Device Sharing: Most devices are shared at some granularity by processes on a general purpose computer. It's the I/O system's job to make surethat sharing is fair (for some fairness metric) and efficient.
• Error Handling: Devices can often deal with errors without user input - retrying a disk read or something similar. Fatal errors need to becommunicated to the user in an understandable manner as well. Furthermore, although hiding errors can be good at some level, at other levels they should beseen. Users must be able to tell that their disks are slowly failing.
• Synchrony and Asynchrony: The I/O system needs to deal with the fact that external devices are not synchronized with the internal clock of theCPU. Events on disk drives occur without any regard for the state of the CPU, and the CPU must deal with that. The I/O system code is what turns theasynchronous interrupts into system events that can be handled by the CPU.