Chapter 4

I/O Management
 Categories in I/O Devices

External devices that engage in I/O with computer

systems can be grouped into three categories:
 Differences in I/O Devices

• Devices differ in a number of areas:

 I/O Management
• I/O management is one of the main functions of the
operating system - to control all the computers
I/O devices.
• 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.
 I/O Hardware

• I/O devices can be roughly divided into two categories:

– block devices -
– character devices

• Block devices store information in fixed-size blocks, each

with its own address.
• The essential property of block devices is that it is possible
to read or write each block independently of all other.
• Disks are the most common block devices
– it is always possible to seek for another cylinder and then wait for
the required block to rotate under the head , no matter where the
arm currently is
 I/O Hardware (cont)

• Character device - A character device

delivers or accepts streams of characters,
without regard to any block structure.
• It is not addressable and does not have
any seek operation.
• Printers, Mice, keyboards and other devices
that are not disk-like can be seen as
character devices.
 I/O Hardware (cont)

• The above classification is not perfect, as some devices

do not fit in either. Clocks, for example, are not block
addressable, neither do they generate or accept character
streams.
• There are other classifications that have also been used, for
example,
– Those that can be accessed sequentially or randomly,
– Those that transfer data synchronously or
asynchronously.
– Dedicated or shared. Operating systems need to
handle all devices despite these variations.
 I/O Hardware (cont)

• Goal of I/O subsystem - provide the simplest

interface possible to the rest of the system.
• A device communicates with a computer system
by sending signals over a cable or even through
the air.
• The device communicates with computer via a
connection point termed as a port.
• If one or more devices use a common set of
wires, the connection is called a bus.
 Device Controllers
• I/O units typically consist of a mechanical
component and an electronic component.
• The electronic component is called the
device controller or adapter.
– A device controller is a collection of electronics
that can operate a port, a bus or a device.
– On PCs, it often takes the form of a printed
circuit card that can be inserted into a slot on
the computer’s parent board.
 Device Controllers (cont)
• The mechanical component is the device
itself.
• 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 a several identical
devices.
• The interface between the controller and
the device is standard interface
 Device Controllers (cont)
• OS deals with the controller and not the
device.
• To encapsulate the details and oddities of different
devices, the operating system is structured to use
device driver modules.
• The device drivers present a uniform device
access interface to the I/O subsystem, much as
system calls provide a standard interface between
the application and the operating system.
 Device Controllers (cont)
• Each controller has a few registers that are used for
communicating with the CPU.
• On some computers these registers are part of the regular
memory address space.
– This scheme is called memory-mapped I/O.

• In addition to I/O ports, many controllers use interrupts to

tell the CPU when they are ready for their registers to be read
or written.
– An interrupt is an electrical event. Hardware Interrupt ReQuest line
(IRQ) is a physical input to the interrupt controller.

• Some controllers are hardwired onto the system parent

board, for example the keyboard controller.
 Device Controllers (cont)
• OS performs I/O by writing commands onto the
controller’s registers.
– For example, the floppy disk controller accepts 15 different
commands, such as READ, WRITE, SEEK, FORMAT, etc.

• When a command has been accepted, the CPU can

leave the controller alone and do other work.
• When the command has been executed, the controller
causes an interrupt in order to allow the OS gain
control of the CPU and test the results of the operation.
• The CPU gets the results and device status by reading
from the controller’s registers.
 Ways to Access a Device

• How to input and output data to and from

an I/O device?
– Polling
– Interrupt-driven I/Os
– Direct memory access (DMA)
– Double Buffering
 Polling
• CPU repeatedly checks the status of a device for exchanging data
+ Simple
- Busy-waiting
• Communication between the host and controller can take the simple
protocol of handshaking.
• We assume that 2 bits are used to co-ordinate the controller and
the host.
– Controller indicates its state through the busy bit and status
register.
– Controller sets the busy bit when it is busy working.
– And clears it when it is ready to accept the next command.
• The host sets the command-ready bit when a command is available
for the controller to execute.
 Interrupts-Driven I/Os

• A device controller notifies the

corresponding device driver when the
device is available
+ More efficient use of CPU cycles
- Data copying and movements
- Slow for character devices (i.e., one interrupt
per keyboard input)
 Direct Memory Access (DMA)

• Uses an additional controller to perform

data movements
+ CPU is not involved in copying data
- I/O device is much more complicated (need to
have the ability to access memory).
- A process cannot access in-transit data
 DMA (cont)
• Many controllers, especially those for block devices,
support Direct Memory Access (DMA).
• When DMA is not used, the following happens.
– First the controller reads the block from the drive
serially, bit by bit, until the entire block is in the
controller’s internal buffer.
– Next, it computes the checksum bit to verify that no
read errors have occurred.
– Then the controller causes an interrupt.
– OS can read the disk block from the controller’s buffer
byte by byte or a word at a time by executing a loop.
 DMA (cont)
• The CPU gives the controller two items of information, in
addition to the disk address of the block:
– the memory address where the block is to go and
– the number of bytes to store.

• After the controller has read the entire block from the device
into its buffer and verified the checksum, it copies the first
byte or word into the main memory at the address specified
by the DMA memory address.
• Then it increments the DMA address and decrements the
DMA count by the number of bytes just transferred.
• This process is repeated until the DMA count becomes zero
at which time the controller causes an interrupt.
 I/O Buffering

• Reasons for buffering

– Processes must wait for I/O to complete
before proceeding
– Certain pages must remain in main memory
during I/O
 I/O Buffering

• Block-oriented
– Information is stored in fixed sized blocks
– Transfers are made a block at a time
– Used for disks and USB keys

• Stream-oriented
– Transfer information as a stream of bytes
– Used for terminals, printers, communication ports,
mouse and other pointing devices, and most other
devices that are not secondary storage
 Single Buffer

• Operating system assigns a buffer in main

memory for an I/O request
• Block-oriented
– Input transfers made to buffer
– Block moved to user space when needed
– Another block is moved into the buffer
• Read ahead
 Single Buffer

• Block-oriented
– User process can process one block of data
while next block is read in
– Swapping can occur since input is taking
place in system memory, not user memory
– Operating system keeps track of assignment
of system buffers to user processes
 Single Buffer

• Stream-oriented
– Used a line at time
– User input from a terminal is one line at a time
with carriage return signaling the end of the
line
– Output to the terminal is one line at a time
Single Buffer
 Double Buffer

• Use two system buffers instead of one

• A process can transfer data to or from one
buffer while the operating system empties
or fills the other buffer
 I/O Software

• Basic idea of I/O software - to organize it as a

series of layers,
– lower layers concerned with the hiding of peculiarities
of the hardware from the upper ones and
– upper ones concerned with presenting a clean, nice
and regular interface to the users

• Device independence - key concept in I/O

software design .
– Should be possible to write programs that can read files
on a floppy disk, hard disk or a CD-ROM without having
to modify the programs for each different device type.
 I/O Software Issues
• Uniform naming - name of a file or device should simply be a
string of characters or an integer not dependent on the device in
any way.
• Error handling - Errors should be handled as close to the
hardware as possible.
– If the controller discovers a read error, it should try to correct the error if it
can.
– If it can’t then the device driver should handle it, perhaps by trying to read
the block again.

• Most errors are transient and if the operation is repeated they go

way.
• Upper layers only handle errors that cannot be addressed by
lower layers.
 I/O Software Issues (cont)

• Synchronous (blocking) versus asynchronous

(interrupt driven) transfersd
– Most physical I/O is asynchronous – CPU starts the
transfer and goes to do something else until the
interrupt arrives.
– User programs are much easier to write if the I/O
operations are blocking – after a READ operation the
program is suspended until the data is available in
the buffer.
– It is up to the OS to make operations that are
interrupt driven look blocking to the user programs.
 I/O Software Issues (cont)

• Sharable versus dedicated devices.

– Some I/O devices such as disks and printers can be used by many users
at the same time.
– There is no problem with multiple users having open files on the
same disk at the same time.
– Other devices like tape drives have to be dedicated to a single user.
– OS should be able to handle shared and dedicated devices.

• These software issues can be achieved in an efficient way by

structuring I/O software in four layers:
1. Interrupt Handlers
2. Device Drivers
3. Device-independent Operating System Software
4. User-level Software
 Interrupt Handlers

• Interrupts should be hidden from users by OS.

• The best way to hide them is to have every process starting
an I/O operation block until the I/O has completed and the
interrupt occurs.
– Process can block itself by doing a DOWN on a semaphore, WAIT on
a condition variable or a RECEIVE on a message, for example.

• When the interrupt happens, the interrupt procedure does

whatever it has to do in order to unblock the process that
started it.
– It might do an UP on a semaphore or a SIGNAL on a condition
variable.

• The process that was blocked will now be able to run.

 Device Drivers
• All the device-dependent code goes in the device drivers.
• Each device driver handles one device type or at most one
class of related devices.
– For example, it would be good to have a single terminal
driver, even if the system supported several different
brands of terminals, all slightly different.
• Device drivers issue commands and check that they are
carried out properly.
– Thus the disk driver is the only part of the OS that
knows how many registers that disk controller has and
what they are used for.
 Device Drivers (cont)
• The work of a device driver is to accept requests from the device-
independent software above it and ensure that the request is
executed.
• A typical request is to read block n.
– If the driver is idle at the point of the request, it carries it out immediately.
– If not, it queues it in its queue of pending requests to be dealt with as soon as
possible.
• The first step in carrying out the request for a disk, for instance, is to
translate it from abstract to concrete terms.
• This means the device driver has to locate the block on disk, check if
the drive motor is running, and determine if the arm is positioned on the
proper cylinder and so on.
• That is, it must determine what controller operations are required and
in what sequence.
 Device Drivers (cont)

• The device driver then issues the commands.

– In most cases, it blocks until an interrupt comes to
unblock it.
– In other cases it doesn’t have to block.

• Once the operation has been completed, it

checks for errors.
– If everything is okay, it might have some data to
pass to the device-independent software.
– If there are more requests, it processes them;
otherwise, it blocks waiting for the next request
 Device Independent I/O Software

• The boundary between drivers and device independent

software is system dependent, because some functions
that could be done in a device-independent way may be
done in the drivers for efficiency or other reasons. The
following functions are normally done in device-independent
software.
1. Uniform interfacing for device drivers
2. Device naming and protection
3. Providing a device-independent block size
4. Buffering
5. Storage allocation on block devices
6. Allocating and releasing dedicated drivers
7. Error reporting
 Device Independent I/O Software (cont)

• Basic function of the device-independent software - to

perform the I/O functions that are common to all
devices and provide a uniform interface to the user-
level software.
• A major issue in operating system is how files and I/O
devices are named.
• The device-independent software takes care of mapping
symbolic device names to the proper drivers.
• Closely related to naming is protection.
– How does the system prevent users from accessing files and
devices they are not entitled to access?.
 Device Independent I/O Software (cont)

• Different disks - may have different sector sizes.

– It is up to the device-independent software to hide this fact and provide a uniform block size to
upper layers
• Also some devices deliver their data one byte at a time (modems), while others deliver theirs
as a block (NIC).
– These differences must be hidden.
• Buffering is also an issue for both character and block devices.
• When a file is created and filled with data, the new disk blocks have to be allocated to the
file.
– To perform this, the OS needs a list or bit map of free blocks per disk, but the allocation
algorithm is device independent and can be done above the level of the driver.
• Some devices can only be used by one process at a time.
• It is up to the OS to examine requests and for device usage and accept or reject them
depending on whether the device is available or not. \
• The device driver does error handling.
– The driver reports the error to the system dependent software then how it is treated from there on is
device independent.
 User Space I/O Software

• Although most of the I/O software is within

the operating system, a small portion of
it consists of libraries linked together
with user programs and other programs
running outside the kernel.
• System calls, including the I/O system
calls are normally made by library
procedures.
 User Space I/O Software
• Not all user-level I/O software consists of library procedures.
• Another important category is the spooling system.
• Spooling is a way of dealing with dedicated I/O devices in a
multiprogramming system
• Consider a typical spooled device: a printer.
– What is normally done is to create a special process called a daemon, and a
special directory called a spooling directory.
– To print a file, a process normally generates the entire file to be printed and
puts it in the spooling directory.
– It is up to the daemon which is the only process having permission to use
the printer’s special directory to print the files in the directory.
• Spooling is also used in the network by a network daemon.
– To send a file somewhere, a user puts it in a network spooling directory.
– Later on, the network daemon takes it out and transmits it.
Summary of the I/O system
 Assignment

• Discuss disk management with relation to

Access time and its components, and Mean
time to failure (MTTF)
•  Explain how the following approaches to
optimize disk-block access
– Disk-arm
– File organization
– Non-volatile write buffers
– Log disk