Principles of Operating Systems

Input/Output
I/O devices - terminology


Device (mechanical hardware)

Device controller (electrical hardware)

Device driver (software)
Example devices and their controllers

Monitor

Bus


Components of a simple personal computer
Device controllers


The Device vs. its Controller

Some duties of a device controller:

Interface between CPU and the Device

Start/Stop device activity

Convert serial bit stream to a block of bytes

Deal with errors
• Detection / Correction

Move data to/from main memory


Some controllers may handle several (similar) devices
Device Driver


A device driver is a software module, that controls various I/O device through
the device controller
Performance challenges: I/O software


How to prevent CPU throughput from being limited by I/O device speed (for
slow devices)

Why would slow devices affect the CPU?


How to prevent I/O throughput from being limited by CPU speed (for fast
devices)

Why would device throughput be limited by the CPU?


How to achieve good utilization of CPU and I/O devices


How to meet the real-time requirements of devices
Input/Output functions


There are three techniques for performing input/ouput:

Programmed I/O

Interrupt-Driven I/O

Direct Memory Access
Programmed I/O


The programmed I/O, the most simple type of I/O technique for the
exchanges of data or any types of communication between the
processor and the external devices.

With programmed I/O, data are exchanged between the processor
and the I/O module.

The processor executes a program that gives it direct control of the
I/O operation, including sensing device status, sending a read or
write command, and transferring the data.

When the processor issues a command to the I/O module, it must
wait until the I/O operation is complete.
Programmed I/O


If the processor is faster than the I/O module, this is wasteful of processor time.
The overall operation of the programmed I/O can be summaries as follow:

The processor is executing a program and encounters an instruction relating to
I/O operation.

The processor then executes that instruction by issuing a command to the
appropriate I/O module.

The I/O module will perform the requested action based on the I/O command
issued by the processor (READ/WRITE) and set the appropriate bits in the I/O
status register.

The processor will periodically check the status of the I/O module until it find
that the operation is complete.
Interrupt-Driven I/O

Interrupt driven I/O is an alternative scheme dealing with I/O.

Interrupt I/O is a way of controlling input/output activity whereby a peripheral
or terminal that needs to make or receive a data transfer sends a signal.

This will cause a program interrupt to be set. At a time appropriate to the
priority level of the I/O interrupt. Relative to the total interrupt system, the
processors enter an interrupt service routine.

The function of the routine will depend upon the system of interrupt levels and
priorities that is implemented in the processor.

The interrupt technique requires more complex hardware and software, but
makes far more efficient use of the computer’s time and capacities
Hardware support for interrupts

How interrupts happen. Connections between devices and interrupt controller actually use
interrupt lines on the bus rather than dedicated wires
Problem with Interrupt driven I/O


Problem:

CPU is still involved in every data transfer

Interrupt handling overhead is high

Overhead cost is not amortized over much data

Overhead is too high for fast devices
• Gbps networks
• Disk drives
Direct Memory Access (DMA)


Data transferred from device straight to/from memory


CPU not involved


The DMA controller:

Does the work of moving the data

CPU sets up the DMA controller (“programs it”)

CPU continues

The DMA controller moves the bytes
Direct Memory Access (DMA)
Direct Memory Access (DMA)


Cycle Stealing

DMA Controller acquires control of bus

Transfers a single byte (or word)

Releases the bus

The CPU is slowed down due to bus contention


Burst Mode

DMA Controller acquires control of bus

Transfers all the data

Releases the bus

The CPU operation is temporarily suspended
Direct Memory Access (DMA)


Cycle Stealing

DMA controller acquires control of bus

Transfers a single byte (or word)

Releases the bus

The CPU is slowed down due to bus contention

Responsive but not very efficient


Burst Mode

DMA Controller acquires control of bus

Transfers all the data

Releases the bus

The CPU operation is suspended

Efficient but interrupts may not be serviced in a timely way
Principles of I/O software


Device Independence

Programs can access any I/O device
• Hard Drive, CD-ROM, Floppy,...
• ... without specifying the device in advance


Uniform Naming

Devices / Files are named with simple strings

Names should not depend on the device


Error Handling

...should be as close to the hardware as possible

… because its often device-specific
Principles of I/O software


Synchronous vs. Asynchronous Transfers

Process is blocked vs. interrupt-driven or polling approaches


Buffering

Data comes off a device

May not know the final destination of the data
• e.g., a network packet... Where to put it???


Sharable vs. Dedicated Devices

Disk should be sharable

Keyboard, Screen dedicated to one process
Software engineering-related challenges


How to remove the complexities of I/O handling from application programs

Solution
• standard I/O APIs (libraries and system calls)


How to support a wide range of device types on a wide range of operating
systems

Solution
• standard interfaces for device drivers (DDI)
• standard/published interfaces for access to kernel facilities (DKI)
I/O software layers
I/O software layers
Interrupt handling


I/O Device Driver starts the operation

Then blocks until an interrupt occurs

Then it wakes up, finishes, & returns


The Interrupt Handler

Does whatever is immediately necessary

Then unblocks the driver


Example: The BLITZ “DiskDriver”

Start I/O and block (waits on semaphore)

Interrupt routine signals the semaphore & returns
 Interrupt handlers – top/bottom halves


Interrupt handlers are divided into scheduled and non scheduled tasks

Non-scheduled tasks execute immediately on interrupt and run in the context of
the interrupted thread

Ie. There is no VM context switch

They should do a minimum amount of work so as not to disrupt progress of
interrupted thread

They should minimize time during which interrupts are disabled


Scheduled tasks are queued for processing by a designated thread

This thread will be scheduled to run later

May be scheduled preemptively or nonpreemptively
Basic activities of an interrupt handler

Set up stack for interrupt service procedure

Ack interrupt controller, reenable interrupts

Copy registers from where saved

Run service procedure
I/O software layers
Device drivers in kernel space
Device drivers


Device drivers are device-specific software that connects devices with the
operating system

Typically a nasty assembly-level job
• Must deal with hardware-specific details (and changes)
• Must deal with O.S. specific details (and changes)

Goal: hide as many device-specific details as possible from higher level
software


Device drivers are typically given kernel privileges for efficiency

Bugs can bring down the O.S.!

Open challenge: how to provide efficiency and safety???
I/O software layers
Device-independent I/O software


Functions and responsibilities

Uniform interfacing for device drivers

Buffering

Error reporting

Allocating and releasing dedicated devices

Providing a device-independent block size
Device-independent I/O software

Device Driver Interface (DDI) and Device Kernel Interface (DKI)

(a) Unbuffered input


Before mounting,

files on floppy are inaccessible

After mounting floppy on b,

files on floppy are part of file hierarchy
I/O software layers
Communicating across the I/O layers