operation system

  

Do the following problems at the end of Chapter 5 in the textbook: 2,4,5*,14,16,18*,23,31Do the following problems at the end of Chapter 6 in the textbook: 1,5,6*,10,14,21,34
modern_operating_systems_fourth_edition.docx

Unformatted Attachment Preview

5
INPUT/OUTPUT
In addition to providing abstractions such as processes, address spaces, and files, an operating system also
controls all the computer’s I/O (Input/Output) de- vices. It must issue commands to the devices, catch
interrupts, and handle errors. It should also provide an interface between the devices and the rest of the
system that is simple and easy to use. To the extent possible, the interface should be the same for all
devices (device independence). The I/O code represents a significant fraction of the total operating
system. How the operating system manages I/O is the subject of this chapter.
This chapter is organized as follows. We will look first at some of the prin- ciples of I/O hardware and
then at I/O software in general. I/O software can be structured in layers, with each having a well-defined
task. We will look at these layers to see what they do and how they fit together.
Next, we will look at several I/O devices in detail: disks, clocks, keyboards, and displays. For each device
we will look at its hardware and software. Finally, we will consider power management.
5.1 PRINCIPLES OF I/O HARDWARE
Different people look at I/O hardware in different ways. Electrical engineers look at it in terms of chips,
wires, power supplies, motors, and all the other physi- cal components that comprise the hardware.
Programmers look at the interface
337
338 INPUT/OUTPUT CHAP. 5
presented to the software—the commands the hardware accepts, the functions it carries out, and the errors
that can be reported back. In this book we are concerned with programming I/O devices, not designing,
building, or maimtaining them, so our interest is in how the hardware is programmed, not how it works
inside. Never- theless, the programming of many I/O devices is often intimately connected with their
internal operation. In the next three sections we will provide a little general background on I/O hardware
as it relates to programming. It may be regarded as a review and expansion of the introductory material in
Sec. 1.3.
5.1.1 I/O Devices
I/O devices can be roughly divided into two categories: block devices and character devices. A block
device is one that stores information in fixed-size blocks, each one with its own address. Common block
sizes range from 512 to 65,536 bytes. All transfers are in units of one or more entire (consecutive) blocks.
The essential property of a block device is that it is possible to read or write each block independently of
all the other ones. Hard disks, Blu-ray discs, and USB sticks are common block devices.
If you look very closely, the boundary between devices that are block address- able and those that are not
is not well defined. Everyone agrees that a disk is a block addressable device because no matter where the
arm currently is, it is always possible to seek to another cylinder and then wait for the required block to
rotate under the head. Now consider an old-fashioned tape drive still used, sometimes, for making disk
backups (because tapes are cheap). Tapes contain a sequence of blocks. If the tape drive is given a
command to read block N, it can always rewind the tape and go forward until it comes to block N. This
operation is analogous to a disk doing a seek, except that it takes much longer. Also, it may or may not be
pos- sible to rewrite one block in the middle of a tape. Even if it were possible to use tapes as random
access block devices, that is stretching the point somewhat: they are normally not used that way.
The other type of I/O device is the character device. A character device deliv- ers or accepts a stream of
characters, without regard 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 experiments), and
most other devices that are not disk-like can be seen as character devices.
This classification scheme is not perfect. Some devices do not fit in. Clocks, for example, are not block
addressable. Nor do they generate or accept character streams. All they do is cause interrupts at welldefined intervals. Memory-mapped screens do not fit the model well either. Nor do touch screens, for that
matter. Still, the model of block and character devices is general enough that it can be used as a basis for
making some of the operating system software dealing with I/O device in- dependent. The file system, for
example, deals just with abstract block devices and leaves the device-dependent part to lower-level
software.
SEC. 5.1 PRINCIPLES OF I/O HARDWARE 339
I/O devices cover a huge range in speeds, which puts considerable pressure on the software to perform
well over many orders of magnitude in data rates. Figure 5-1 shows the data rates of some common
devices. Most of these devices tend to get faster as time goes on.
Device
Data rate
Keyboard
10 bytes/sec
Mouse
100 bytes/sec
56K modem
7 KB/sec
Scanner at 300 dpi
1 MB/sec
Digital camcorder
3.5 MB/sec
4x Blu-ray disc
18 MB/sec
802.11n Wireless
37.5 MB/sec
USB 2.0
60 MB/sec
FireWire 800
100 MB/sec
Gigabit Ethernet
125 MB/sec
SATA 3 disk drive
600 MB/sec
USB 3.0
625 MB/sec
SCSI Ultra 5 bus
640 MB/sec
Single-lane PCIe 3.0 bus 985 MB/sec
Thunderbolt 2 bus
2.5 GB/sec
SONET OC-768 network 5 GB/sec
Figure 5-1. Some typical device, network, and bus data rates.
5.1.2 Device Controllers
I/O units often consist of a mechanical component and an electronic compo- nent. It is possible to
separate the two portions to provide a more modular and general design. The electronic component is
called the device controller or adapter. On personal computers, it often takes the form of a chip on the
par- entboard or a printed circuit card that can be inserted into a (PCIe) expansion slot. The mechanical
component is the device itself. This arrangement is shown in Fig. 1-6.
The controller card usually has a connector on it, into which a cable leading to the device itself can be
plugged. Many controllers can handle two, four, or even eight identical devices. If the interface between
the controller and device is a stan- dard interface, either an official ANSI, IEEE, or ISO standard or a de
facto one, then companies can make controllers or devices that fit that interface. Many com- panies, for
example, make disk drives that match the SATA, SCSI, USB, Thunder- bolt, or FireWire (IEEE 1394)
interfaces.
340 INPUT/OUTPUT CHAP. 5
The interface between the controller and the device is often a very low-level one. A disk, for example,
might be formatted with 2,000,000 sectors of 512 bytes per track. What actually comes off the drive,
however, is a serial bit stream, start- ing with a preamble, then the 4096 bits in a sector, and finally a
checksum, or ECC (Error-Correcting Code). The preamble is written when the disk is for- matted and
contains the cylinder and sector number, the sector size, and similar data, as well as synchronization
information.
The controller’s job is to convert the serial bit stream into a block of bytes and perform any error
correction necessary. The block of bytes is typically first assem- bled, bit by bit, in a buffer inside the
controller. After its checksum has been veri- fied and the block has been declared to be error free, it can
then be copied to main memory.
The controller for an LCD display monitor also works as a bit serial device at an equally low level. It
reads bytes containing the characters to be displayed from memory and generates the signals to modify
the polarization of the backlight for the corresponding pixels in order to write them on screen. If it were
not for the display controller, the operating system programmer would have to explicitly pro- gram the
electric fields of all pixels. With the controller, the operating system ini- tializes the controller with a few
parameters, such as the number of characters or pixels per line and number of lines per screen, and lets
the controller take care of actually driving the electric fields.
In a very short time, LCD screens have completely replaced the old CRT (Cathode Ray Tube) monitors.
CRT monitors fire a beam of electrons onto a flu- orescent screen. Using magnetic fields, the system is
able to bend the beam and draw pixels on the screen. Compared to LCD screens, CRT monitors were
bulky, power hungry, and fragile. Moreover, the resolution on today ́s (Retina) LCD screens is so good
that the human eye is unable to distinguish individual pixels. It is hard to imagine today that laptops in the
past came with a small CRT screen that made them more than 20 cm deep with a nice work-out weight of
around 12 kilos.
5.1.3 Memory-Mapped I/O
Each controller has a few registers that are used for communicating with the CPU. By writing into these
registers, the operating system can command the de- vice to deliver data, accept data, switch itself on or
off, or otherwise perform some action. By reading from these registers, the operating system can learn
what the device’s state is, whether it is prepared to accept a new command, and so on.
In addition to the control registers, many devices have a data buffer that the op- erating system can read
and write. For example, a common way for computers to display pixels on the screen is to have a video
RAM, which is basically just a data buffer, available for programs or the operating system to write into.
The issue thus arises of how the CPU communicates with the control registers and also with the device
data buffers. Two alternatives exist. In the first approach,
SEC. 5.1 PRINCIPLES OF I/O HARDWARE 341
each control register is assigned an I/O port number, an 8- or 16-bit integer. The set of all the I/O ports
form the I/O port space, which is protected so that ordinary user programs cannot access it (only the
operating system can). Using a special I/O instruction such as
IN REG,PORT,
the CPU can read in control register PORT and store the result in CPU register
REG.
Similarly, using OUT PORT,REG
the CPU can write the contents of REG to a control register. Most early computers, including nearly all
mainframes, such as the IBM 360 and all of its successors, worked this way.
In this scheme, the address spaces for memory and I/O are different, as shown in Fig. 5-2(a). The
instructions
IN R0,4
and
MOV R0,4
are completely different in this design. The former reads the contents of I/O port 4 and puts it in R0
whereas the latter reads the contents of memory word 4 and puts it in R0. The 4s in these examples refer
to different and unrelated address spaces.
Two address 0xFFFF…
0
(a)
Figure 5-2. (a) Separate I/O and memory space. (b) Memory-mapped I/O. (c) Hybrid.
One address space Two address spaces
Memory
I/O ports
The second approach, introduced with the PDP-11, is to map all the control registers into the memory
space, as shown in Fig. 5-2(b). Each control register is assigned a unique memory address to which no
memory is assigned. This system is called memory-mapped I/O. In most systems, the assigned addresses
are at or near the top of the address space. A hybrid scheme, with memory-mapped I/O data buffers and
separate I/O ports for the control registers, is shown in Fig. 5-2(c).
(b)
(c)
342 INPUT/OUTPUT CHAP. 5
The x86 uses this architecture, with addresses 640K to 1M 1 being reserved for device data buffers in
IBM PC compatibles, in addition to I/O ports 0 to 64K 1.
How do these schemes actually work in practice? In all cases, when the CPU wants to read a word, either
from memory or from an I/O port, it puts the address it needs on the bus’ address lines and then asserts a
READ signal on a bus’ control line. A second signal line is used to tell whether I/O space or memory space
is needed. If it is memory space, the memory responds to the request. If it is I/O space, the I/O device
responds to the request. If there is only memory space [as in Fig. 5-2(b)], every memory module and
every I/O device compares the address lines to the range of addresses that it services. If the address falls
in its range, it re- sponds to the request. Since no address is ever assigned to both memory and an I/O
device, there is no ambiguity and no conflict.
These two schemes for addressing the controllers have different strengths and weaknesses. Let us start
with the advantages of memory-mapped I/O. Firstof all, if special I/O instructions are needed to read and
write the device control registers, access to them requires the use of assembly code since there is no way
to execute an IN or OUT instruction in C or C++. Calling such a procedure adds overhead to controlling
I/O. In contrast, with memory-mapped I/O, device control registers are just variables in memory and can
be addressed in C the same way as any other var- iables. Thus with memory-mapped I/O, an I/O device
driver can be written entirely in C. Without memory-mapped I/O, some assembly code is needed.
Second, with memory-mapped I/O, no special protection mechanism is needed to keep user processes
from performing I/O. All the operating system has to do is refrain from putting that portion of the address
space containing the control regis- ters in any user’s virtual address space. Better yet, if each device has
its control registers on a different page of the address space, the operating system can give a user control
over specific devices but not others by simply including the desired pages in its page table. Such a scheme
can allow different device drivers to be placed in different address spaces, not only reducing kernel size
but also keeping one driver from interfering with others.
Third, with memory-mapped I/O, every instruction that can reference memory can also reference control
registers. For example, if there is an instruction, TEST, that tests a memory word for 0, it can also be used
to test a control register for 0, which might be the signal that the device is idle and can accept a new
command. The assembly language code might look like this:
// check if port 4 is 0
// if it is 0, go to ready
// otherwise, continue testing
LOOP: TEST PORT 4 BEQ READY
BRANCH LOOP
READY:
If memory-mapped I/O is not present, the control register must first be read into the CPU, then tested,
requiring two instructions instead of just one. In the case of
SEC. 5.1 PRINCIPLES OF I/O HARDWARE 343
the loop given above, a fourth instruction has to be added, slightly slowing down the responsiveness of
detecting an idle device.
In computer design, practically everything involves trade-offs, and that is the case here, too. Memorymapped I/O also has its disadvantages. First, most com- puters nowadays have some form of caching of
memory words. Caching a device control register would be disastrous. Consider the assembly-code loop
given above in the presence of caching. The first reference to PORT 4 would cause it to be cached.
Subsequent references would just take the value from the cache and not even ask the device. Then when
the device finally became ready, the software would have no way of finding out. Instead, the loop would
go on forever.
To prevent this situation with memory-mapped I/O, the hardware has to be able to selectively disable
caching, for example, on a per-page basis. This feature adds extra complexity to both the hardware and
the operating system, which has to man- age the selective caching.
Second, if there is only one address space, then all memory modules and all I/O devices must examine all
memory references to see which ones to respond to. If the computer has a single bus, as in Fig. 5-3(a),
having everyone look at every address is straightforward.
CPU reads and writes of memory go over this high-bandwidth bus
This memory port is to allow I/O devices access to memory
(b)
Figure 5-3. (a) A single-bus architecture. (b) A dual-bus memory architecture.
However, the trend in modern personal computers is to have a dedicated high- speed memory bus, as
shown in Fig. 5-3(b). The bus is tailored to optimize memo- ry performance, with no compromises for the
sake of slow I/O devices. x86 sys- tems can have multiple buses (memory, PCIe, SCSI, and USB), as
shown in Fig. 1-12.
The trouble with having a separate memory bus on memory-mapped machines is that the I/O devices have
no way of seeing memory addresses as they go by on the memory bus, so they have no way of responding
to them. Again, special meas- ures have to be taken to make memory-mapped I/O work on a system with
multiple
CPU
Memory
I/O
CPU
Memory
I/O
All addresses (memory and I/O) go here
(a)
Bus
344 INPUT/OUTPUT CHAP. 5
buses. One possibility is to first send all memory references to the memory. If the memory fails to
respond, then the CPU tries the other buses. This design can be made to work but requires additional
hardware complexity.
A second possible design is to put a snooping device on the memory bus to pass all addresses presented to
potentially interested I/O devices. The problem here is that I/O devices may not be able to process
requests at the speed the memory can.
A third possible design, and one that would well match the design sketched in Fig. 1-12, is to filter
addresses in the memory controller. In that case, the memory controller chip contains range registers that
are preloaded at boot time. For ex- ample, 640K to 1M 1 could be marked as a nonmemory range.
Addresses that fall within one of the ranges marked as nonmemory are forwarded to devices in- stead of
to memory. The disadvantage of this scheme is the need for figuring out at boot time which memory
addresses are not really memory addresses. Thus each scheme has arguments for and against it, so
compromises and trade-offs are inevitable.
5.1.4 Direct Memory Access
No matter whether a CPU does or does not have memory-mapped I/O, it needs to address the device
controllers to exchange data with them. The CPU can request data from an I/O controller one byte at a
time, but doing so wastes the CPU’s time, so a different scheme, called DMA (Direct Memory Access)
is often used. To simplify the explanation, we assume that the CPU accesses all devices and memory via a
single system bus that connects the CPU, the memory, and the I/O devices, as shown in Fig. 5-4. We
already know that the real organization in modern systems is more complicated, but all the principles are
the same. The operating system can use only DMA if the hardware has a DMA controller, which most
systems do. Sometimes this controller is integrated into disk controllers and other controllers, but such a
design requires a separate DMA controller for each device. More com- monly, a single DMA controller is
available (e.g., on the parentboard) for regulat- ing transfers to multiple devices, often concurrently.
No matter where it is physically located, the DMA controller has access to the system bus independent of
the CPU, as shown in Fig. 5-4. It contains several reg- isters that can be written and read by the CPU.
These include a memory address register, a byte count register, and one or more control registers. The
control regis- ters specify the I/O port to use, the direction of the transfer (reading from the I/O device or
writing to the I/O device), the transfer unit (byte at a time or word at a time), and the number of bytes to
transfer in one burst.
To explain how DMA works, let us first look at how disk reads occur when DMA is not used. First the
disk controller reads the block (one or more sectors) from the drive serially, bit by bit, until the entire
block is in the controller’s internal buffer. Next, it computes the checksum to verify that no read errors
have occurred.
SEC. 5.1
PRINCIPLES OF I/O HARDWARE
345
CPU
1. CPU programs the DMA controller
Interrupt when done
DMA controller
Disk controller
Drive
Buffer
Main memory
Address
Count
Control
4. Ack
2. DMA requests transfer to memory
3. Data transferred
Bus
Figure 5-4. Operation of a DMA transfer.
Then the controller causes an interrupt. When the operating system starts running, it can read the disk
block from the controller’s …
Purchase answer to see full
attachment