INPUT / OUTPUT

MANAGEMENT

Rutherford, Andrew (Mr) (Summerstrand Campus North)

NELSON MANDELA UNIVERSITY
TABLE OF CONTENTS
TABLE OF CONTENTS .......................................................................................................... 1
Introduction ............................................................................................................................. 2
I/O Devices in General ............................................................................................................ 2
Device Controllers ................................................................................................................... 3
Communication to I/O Devices ............................................................................................... 4
Special Instruction I/O ......................................................................................................... 4
Memory-Mapped I/O ........................................................................................................... 4
Typical Device OS Interaction ............................................................................................. 5
Direct Memory Access (DMA) ............................................................................................. 6
Polling vs Interrupts I/O ....................................................................................................... 7
Polling I/O ........................................................................................................................ 7
Interrupts I/O .................................................................................................................... 7
I/O Software ............................................................................................................................ 8
Device Drivers ..................................................................................................................... 9
Controller vs Driver in a Nutshell ......................................................................................... 9
Interrupt handlers ................................................................................................................ 9
Device-Independent I/O Software ..................................................................................... 10
User-Space I/O Software .................................................................................................. 11
Kernel I/O Subsystem ....................................................................................................... 11
Bibliography .......................................................................................................................... 12

Page 1 of 12
Introduction
The operating system is responsible controls all the computer’s I/O (Input/Output) 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. As far as possible the interface should be the same for all devices (device
independence). Providing a common interface is a tough job as I/O devices vary so widely in
their functionality and speed (for example a mouse, a hard disk and a CD-ROM), varied
methods are required for controlling them.
An I/O system must take an application I/O request and send it to the physical device, then
take whatever response comes back from the device and send it to the application.

I/O Devices in General

I/O devices can be divided into two categories −
• Block devices − A block device is one with which the driver communicates by sending
entire blocks of data. For example, Hard disks, USB cameras, Disk-On-Key etc.
• Character devices − A character device is one with which the driver communicates
by sending and receiving single characters (bytes, octets). For example, serial ports,
parallel ports, sounds cards etc

As seen in Figure 1 device two important components an interface and an internal structure.
The Device Interface is comprised of three registers
• Status Register: Stores the current status of the device
• Command Register: What command to perform.
• Data Register: Data it wants to pass on or has received
The Device Internals
This part of the device is implementation specific and is responsible for implementing the
abstraction the device presents to the system.

Figure 1. Abstraction of a Device

Page 2 of 12
Device Controllers
The Device Controller works like an interface between a device and a device driver. A device
(Keyboard, mouse, printer, etc.) typically consist of a mechanical component and an
electronic component where electronic component is called the device controller.
There is always a device controller and a device driver for each device to communicate with
the Operating System. A device controller may be able to handle multiple devices. As an
interface its main task is to convert serial bit stream to block of bytes, perform error correction
as necessary.
Any device connected to the computer is connected by a plug and socket, and the socket is
connected to a device controller. Following is a model for connecting the CPU, memory,
controllers, and I/O devices where CPU and device controllers all use a common bus for
communication.

Bus
Figure 2. Simple Personal Computer Abstraction

Page 3 of 12
Communication to I/O Devices
The CPU must have a way to pass information to and from an I/O device. There are
three approaches available that enable this communication.

• Special Instruction I/O

• Memory-mapped I/O
• Direct memory access (DMA)

Special Instruction I/O

These instructions specify a way for the OS to send data to specific device registers (see
Figure 1). The OS is the only entity allowed to directly communicate with the devices,

Memory-Mapped I/O
The hardware device makes the registers appear as if they are regular memory locations.
They can therefore be read from and written to as if reading/writing to RAM. When a read or
write operation is performed on these locations, the underlying memory hardware will realize
these memory locations are actually device registers.

Figure 3. Memory Mapped Input Output

Page 4 of 12
Typical Device OS Interaction
The protocol has four steps and is illustrated by the flowchart of Figure 4.
1. OS waits until the device is ready to receive a command by repeatedly reading the
status register.
2. OS sends some data down to the data register.
a. if this were a disk, multiple writes would need to take place to transfer a disk
block (say 4KB) to the device)
b. When the main CPU is involved with the data movement, we refer to it as
programmed I/O (PIO).
3. OS writes a command to the command register.
a. doing so implicitly lets the device know that both the data is present and that
it should begin working on the command.
4. OS waits for the device to finish by again polling it in a loop, waiting to see if it is
finished (it may then get an error code to indicate success or failure).

IO Request

Write Data to
No Status = Busy? Yes Wait
DATA Register Polling

PIO

Write command
To
COMMAND register

No Status = Busy? Yes Wait

Polling

Figure 4. Device OS Interaction

We can identify a few problems

1. Polling is inefficient; it wastes a great deal of CPU time just waiting for the (potentially
slow) device to complete its activity, instead of switching to another ready process
and thus better utilizing the CPU.

2. Using programmed I/O (PIO) to transfer a large chunk of data to a device,

overburdens the CPU with a mundane task, and wastes a lot of time and effort that
could be spent running other processes.

Page 5 of 12
Direct Memory Access (DMA)
Slow devices like keyboards generate an interrupt to the CPU after each byte transfer. If a
fast device e.g. a hard drive, generated an interrupt for each byte, the operating system would
spend most of its time handling these interrupts. Thus, computers use direct memory access
(DMA) hardware to reduce this overhead.
Direct Memory Access (DMA) allows a CPU to grant a DMA engine the authority to read from
or write to memory without CPU involvement. The DMA module controls exchange of data
between main memory and the I/O device. The CPU is only involved at the beginning and
end of the transfer and interrupted only after entire block has been transferred.
Direct Memory Access needs special hardware called the DMA controller (DMAC) that
manages the data transfers and arbitrates access to the system bus. The controllers are
programmed with source and destination pointers (where to read/write the data), counters to
track the number of transferred bytes, and settings, which includes I/O and memory types,
interrupts and states for the CPU cycles.
DMA Works as follows to transfer data to a device,
1. the OS programs the DMA engine by
a. telling it where the data lives in memory,
b. how much data to copy, and
c. which device to send it to.
2. OS/CPU is done with the transfer and can proceed with other work.
3. When the DMA is complete, the DMA controller
a. raises an interrupt, and
b. the OS thus knows the transfer is complete.

Figure 5. Dynamic Memory Access

Page 6 of 12
Polling vs Interrupts I/O
A computer must have a way of detecting the arrival of any type of input. There are two ways
that this can happen

• polling and
• interrupts.
Both techniques allow the processor to deal with events that can happen at any time and
that are not related to the process it is currently running.

Polling I/O
Polling is the simplest way for an I/O device to communicate with the processor. It entails
periodically checking status of the device to see if it is time for the next I/O operation. The I/O
device simply puts the information in a Status register, and the processor must check the
status.
Most of the time, devices will not require attention and when one does it will have to wait until
it is next interrogated by the polling program. This is an inefficient method and much of the
processors time is wasted on unnecessary polls.
Imagine a lecturer continually asking every student in a class, one after another, if they need
help. Obviously the more efficient method would be for a student to inform the teacher
whenever they require assistance.

Interrupts I/O
An interrupt is a signal to the CPU from a device that requires attention. A device controller
puts an interrupt signal on the bus when it needs CPU’s attention. When the CPU receives an
interrupt, it
1. saves its current state and
2. invokes the appropriate interrupt handler
3. When the interrupting device has been dealt with, the CPU continues with its original
task as if it had never been interrupted.

Page 7 of 12
I/O Software
I/O software is often organized in the following layers −
• User Level Libraries − This provides simple interface to the user program to perform
input and output. For example, stdio is a library provided by C and C++ programming
languages.
• Kernel Level Modules − This provides device driver to interact with the device
controller and device independent I/O modules used by the device drivers.
• Hardware − This layer includes actual hardware and hardware controller which
interact with the device drivers and makes hardware alive.
I/O software should be device independent where it should be possible to write programs that
can access any I/O device without having to specify the device in advance. For example, a
program that reads a file as input should be able to read a file on a hard disk, or on a USB
stick, without having to modify the program for each different device.

Figure 6. I/O Software Layers

Page 8 of 12
Device Drivers
There are a wide variety of device types and indeed many manufacturers of these different
device types. Thus, each I/O Device attached to a computer needs some device-specific
code to control it. This code is called the device driver. To add to the mix each manufacturers
device will require a driver for the different Operating Systems it supports
Device drivers are software modules that can be plugged into an OS to handle a particular
device - they provide the all-important means for a computer to interact with hardware
A device driver performs the following jobs −

• To accept request from the device independent software above it.

• Interact with the device controller to take and give I/O and perform required error
handling
• Making sure that the request is executed successfully

https://www.youtube.com/watch?v=z8vWxk3iY4M
A Driver handles a request as follows. If it is idle at the time of the request it carries out the
request immediately. Alternatively, it places the request in the queue of pending requests

Controller vs Driver in a Nutshell

• A device driver is a software program that manages and controls a specific device
that is attached to a computer.
• A device controller is a hardware unit that makes sense of the incoming and outgoing
signals of the CPU

Interrupt handlers
An interrupt handler, also known as an interrupt service routine or ISR, is a piece of software
in a device driver, whose execution is triggered by the reception of an interrupt. When the
interrupt happens,
1. the interrupt procedure does whatever it has to in order to handle the interrupt,
2. updates data structures and
3. wakes up process that was waiting for an interrupt to happen.
The interrupt mechanism accepts an address ─ a number that selects a specific interrupt
handling routine/function from a small set. In most architectures, this address is an offset
stored in a table called the interrupt vector table. This vector contains the memory addresses
of specialized interrupt handlers.

Page 9 of 12
Device-Independent I/O Software
The basic function of the device-independent software is to perform the I/O functions that are
common to all devices and to provide a uniform interface to the user-level software. Though
it is difficult to write completely device independent software, but we can write some modules
which are common among all the devices. Specifically, we can abstract away the detailed
differences in I/O devices by identifying a few general kinds. Each general kind is accessed
through a standardized set of functions—an interface. The differences are encapsulated in
kernel modules called device drivers that internally are custom-tailored to specific devices
but that export one of the standard interfaces

Some functions of device-independent I/O Software

• Uniform interfacing for device drivers
For each class of devices, such as disks or printers, the operating system defines a
set of functions that the driver must supply. For a disk these would naturally include
read and write, but also turning the power on and off, formatting, and other “disky”
things.

• Device naming
The name of a file or a device should simply be a string or an integer and not depend
on the device in any way.

• Device protection
In both UNIX and Windows, devices appear in the file system as named objects,
which means that the usual protection rules for files also apply to I/O devices.

• Providing a device-independent block size

Different disks may have different sector sizes. Device-independent software can
hide this and provide a uniform block size to higher layers, for example, by treating
several sectors as a single logical block.

• Buffering
Because data coming off a device cannot be stored in final destination.

• Allocation and releasing dedicated devices

Some devices can be used by only one process at a time and a device independent
mechanism for requesting and releasing dedicated devices is required. Attempting to
access an unavailable dedicated device should not fail but be placed in queue

• Error Reporting
In general, errors should be handled as close to the hardware as possible.

Page 10 of 12
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 even whole programs running outside the
kernel.
These are the libraries which provide a richer and simplified interface to access the
functionality of the kernel or ultimately interact with device drivers. Most of the user-level I/O
software consists of library procedures with some exception like spooling system which is a
way of dealing with dedicated I/O devices in a multiprogramming system.
I/O Libraries (e.g., stdio) are in user-space to provide an interface to the OS resident device-
independent I/O software. For example, putchar(), getchar(), printf() and scanf() are example
of user level I/O library stdio available in C programming.

Kernel I/O Subsystem

Kernel I/O Subsystem is responsible to provide many services related to I/O. Following are
some of the services provided.
• Scheduling − Kernel schedules a set of I/O requests to determine a good order in
which to execute them. When an application issues a blocking I/O system call, the
request is placed on the queue for that device. The Kernel I/O scheduler arranges the
order of the queue based on a scheduling algorithm.
• Buffering − Kernel I/O Subsystem maintains a memory area known as buffer that
stores data while they are transferred between two devices or between a device with
an application operation. Buffering is done to cope with a speed mismatch between
the producer and consumer of a data stream or to adapt between devices that have
different data transfer sizes.
• Caching − Kernel maintains cache memory which is region of fast memory that holds
copies of data. Access to the cached copy is more efficient than access to the original.
• Spooling and Device Reservation − A spool is a buffer that holds output for a device,
such as a printer. The spooling system copies the queued spool files to the printer
one at a time. In some operating systems, spooling is managed by a system daemon
process. In other operating systems, it is handled by an in-kernel thread.
• Error Handling − An operating system that uses protected memory can guard against
many kinds of hardware and application errors.

Page 11 of 12
Bibliography
Silberschatz, A., Baer Galvin, P., & Gagne, G. (2018). Operating System Concepts.
Hoboken: John Wiley & Sons, Inc.
Tannenbaum, A., & Bos, H. (2015). Modern Operating Systems. New Jersey: Pearson.
Tutorialspoint. (2021, 01 01). Operating System Tutorial. Retrieved from Tutorialspoint.com:
https://www.tutorialspoint.com/operating_system/
W3Schools. (2019, 01 01). Operating System Tutorial Library. Retrieved 2022, from
W3Schools: https://www.w3schools.in/operating-system-tutorial

Page 12 of 12