0% found this document useful (0 votes)
14 views29 pages

Chapter 8 - InputOutput Management

The document discusses the structure and principles of Input/Output (I/O) management within operating systems, highlighting the roles of I/O hardware and software. It covers various types of I/O devices, device controllers, and the importance of device independence, error handling, and buffering in I/O operations. Additionally, it outlines the layers of I/O software, including device drivers and device-independent software, and explains how I/O requests are processed within these layers.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
14 views29 pages

Chapter 8 - InputOutput Management

The document discusses the structure and principles of Input/Output (I/O) management within operating systems, highlighting the roles of I/O hardware and software. It covers various types of I/O devices, device controllers, and the importance of device independence, error handling, and buffering in I/O operations. Additionally, it outlines the layers of I/O software, including device drivers and device-independent software, and explains how I/O requests are processed within these layers.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 29

ITSE 4931

Operating Systems

Software Engineering Department


AAiT
May-2025
Chapter Eight
Input/output Management

2
Chapter Objectives
 To explore the structure of an operating system's I/O
subsystem.
 To discuss the principles and complexities of I/O
hardware.
 To explain the performance aspects of I/O hardware
and software.

3
Topics Included
 Introduction
 Principles of I/O hardware
 Principles of I/O software

4
Introduction
 One of the main functions of an operating system is to
control all the computer's I/O (Input/Output) devices.
 I/O is important for communication between the user and
computer.
 I/O devices vary so widely in their function and speed,
varied methods are needed to control them.
 The following are functions of the operating system as I/O
manager:
 Control all the computer I/O devices.
 Issue commands to I/O devices, catch interrupts and handle errors.
 Provide an interface between the device and the rest of the
system.

5
Principles of I/O Hardware
 Different people look I/O hardware in different ways.
 Electrical engineers look at it in terms of chips, wires, power
supplies, motors, and all the other physical components that
make up the hardware.
 Programmers look at the interface presented to the software
 The commands the hardware accepts, the functions it
carries out, and the errors that can be reported back.
 our interest will be restricted to how the hardware is
programmed, not how it works inside.
 There are two types of I/O devices: block and
character
 Block devices (such as disks) - is one that stores information
in fixed-size blocks, each one with its own address.

6
I/O Devices(cont’d)
 Common block size range from 512 bytes to 32,768 bytes.
 The essential property of a block device is that it is
possible to read or write each block independently of all
the other ones.
 Disks are the most common block devices.
 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.
 Character devices (such as printers, mouse and NIC)
 A character device delivers or accepts stream of character, without
regard to any block structure.
 It is not addressable and does not have any seek operation.

 I/O devices vary so widely in their function and speed


 Varied methods are needed to control them

7
I/O Devices(cont’d)

Some typical device, network, and data rates 8


Device Controllers
 I/O devices have components:
 mechanical component
 The mechanical component is the device itself
 electronic component
 The electronic component is the device controller/adapter

 Controller's tasks
 convert serial bit stream to block of bytes
 perform error correction as necessary
 make available to main memory
 Each controller has a few registers that are used for
communicating with the CPU.

9
Device Controllers(cont’d)
Monitor

Bus

A model for connecting the CPU, memory, controllers,


and I/O devices

10
Memory-Mapped I/O

 Controller has one or more registers for data and control signals.
Processor communicates with control register in one of those
methods:
 Separate I/O and memory space
 Memory-mapped I/O- device-control registers are mapped into
the address space of the processor
 Hybrid 11
Direct Memory Access(DMA)
 A technique for moving a data directly between main
memory and I/O devices without the CPU’s intervention.
 The CPU can request data from an I/O controller one
byte at a time but doing so for a device like a disk that
produces a large block of data wastes the CPU's time.
 In the absence of DMA reading from a disk is done with
the following steps:
 The 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
 The controller computes the checksum to verify that no read
errors have occurred

12
DMA(cont’d)
 The controller causes an interrupt
 The OS reads the disk block from the controller’s buffer a byte
or a word at a time and stores it on memory
 Problem: Since the OS controls the loop of reading it
wastes the CPU time.
 When DMA is used,
 CPU programs the DMA controller so it knows what to transfer
where.
 Tells disk controller to read data from the disk into its internal
buffer and verify the checksum.

13
DMA(cont’d)

Operation of a DMA transfer

14
Principles of I/O Software
 Goals and issues of I/O software:
 Device Independence:
 It should be possible to write programs that can read files on
hard disk or on a CD-ROM, without having to modify the
program for each different device types.
 It is up to the operating system to take care of the problems
caused by the fact that these devices are really different.
 Uniform Naming: the name of a file or a device should
simply be a string or an integer and not dependant on
the device in any way.
 E.g. a file called IAmStoredOnAHardDisk might well be stored
on a CD

15
Principles of I/O Software(cont’d)
 Error handling:
 In general, errors should be handled as close to the hardware as
possible (at the device controller level).
 Only if the lower layers are not be able to deal with the problem
should the upper layers be told about it.
 Transfer:
 There are two types of transfer modes – Synchronous (Blocking)
and Asynchronous (interrupt –driven).
 In the case of synchronous transfer the program requesting I/O
transfer will be suspended until the transfer is completed.
 In the case of Asynchronous transfer the CPU starts the transfer and
goes off to do something until the interrupt that shows the
completion of the transfer arrives.

16
Principles of I/O Software(cont’d)
 Buffering
 data coming off a device cannot be stored in final destination
 For example, when a packet comes in off the network, the operating
system does not know where to put it until it has stored the packet
somewhere and examined it.
 Device types: There are two device types
 Sharable (such as disk) - used by many users at the same time. No
problems are caused by multiple users having open files on the same
disk at the same time.
 Dedicated (tape drives) have to be dedicated to a single user until
that user is finished. Having two or more users writing blocks
intermixed at random to the same tape will definitely not work.

17
Layers of I/O Software
 The following are the I/O software layers
 Interrupt handler (bottom)
 Device driver
 Device independent OS software
 User-level software (top)
 Interrupt Handler
 Interrupts are unpleasant facts of life and cannot be avoided.
They should be hidden away, so that as little of the operating
system as possible knows about them.
 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.
 When the interrupt happens, the interrupt procedure does
whatever it has to in order to unblock the process that started it.

18
Layers of I/O Software(cont’d)

Layers of the I/O Software System

19
Layers of I/O Software(cont’d)
 Device Driver
 Is a device – specific code for controlling I/O devices.
 each device controller has registers used to give it commands or to read
out its status. The number of registers and the nature of the commands
vary radically from device to device.
 For example, a mouse driver has to accept information from the mouse
telling how far it has moved and which buttons are currently depressed.
 In contrast, a disk driver has to know about sectors, tracks, cylinders,
heads, arm motion, motor drives, head settling times, and all the other
mechanics of making the disk work properly. Obviously, these drivers
will be very different.
 Each device driver handles one device type, or at most, one class of closely
related devices.
 In general terms, the job of a device driver is to accept requests form the
device-independent software above it and sees to it that the request is
executed.
 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.

20
Layers of I/O Software(cont’d)

 Logical position of device drivers is shown here

21
Layers of I/O Software(cont’d)
 Steps in carrying out I/O requests:
 Translate it from abstract to concrete terms
 E.g. For disk driver: convert a linear block number into the
head, track, sector, and cylinder numbers for disk`s
geometry.
 Write into the controller’s device registers
 The device driver blocks itself until interrupt comes
 The blocked driver will be awakened by the interrupt
 Device driver checks for errors
 If everything is all right, the driver may have data to pass to
the device independent software
 If nothing is queued, the driver blocks waiting for the next
request

22
Layers of I/O Software(cont’d)
 Device Independent I/O Software
 It is large fraction of I/O software
 Perform the I/O functions that are common to all devices and to
provide a uniform interface to the user-level software.
 Functions of the device-independent I/O software
 Uniform interfacing for device drivers
 A major issue in an operating system is how to make all I/O devices and
drivers look more-or-less the same.
 If disks, printers, monitors, keyboards, etc., are all interfaced in different
ways, every time a new peripheral device comes along, the
operating system must be modified for the new device.
 With a standard interface it is much easier to plug in a new driver. It also
means that driver writers know what is expected of them (e.g., what
functions they must provide and what kernel functions they may call).
 Device Naming – responsible for mapping symbolic devices names onto
the proper driver

23
Layers of I/O Software(cont’d)

(a) Without a standard driver interface


(b) With a standard driver interface

24
Layers of I/O Software(cont’d)
 Providing device-independent block size – provide
uniform block size to higher layers hiding differences in block
sizes.
 Different disks may have different sector size.
 Some devices deliver their data one byte at a time(e.g., modems),
while others deliver theirs in large units(e.g., network interfaces).
 Buffering: if a user process write half a block, the OS will
normally keep the data in buffer until the rest of the data are
written.
 Device protection – prevent users from accessing devices
that they are not entitled to access
 Allocating and releasing dedicated devices: It is up to the OS to
examine requests for devices usage and accept or reject them.
 Error reporting: Errors handling, by and large, is done by drivers.
Most errors are device dependent. After the driver tries to read the
block a certain number of times, it gives up and informs the device-
independent software. It then reports to the caller.

25
Layers of I/O Software(cont’d)

(a) Unbuffered input


(b) Buffering in user space
(c) Buffering in the kernel followed by copying to user
space
(d) Double buffering in the kernel 26
Layers of I/O Software(cont’d)
 User Space I/O Software
 A small portion of the I/O software is outside the OS
 System calls, including the I/O system calls, are normally
made by library procedures.
 E.g. when a C program contains the call count=write (fd,
buffer, nbytes); the library procedure write will be linked with
the program and contained in the binary program present in
memory at run time.
 Formatting of input and output is done by library procedures
 E.g printf(“Value of i is: =%d\n”, i);
 scanf(“%d %d”, &fnumber, &snumber);

27
Layers of I/O Software(cont’d)
 The following is an example how the I/O system works
during reading by an application
 Step 1: the user program produce a system call for reading from
a file
 Step 2: the device-independent software looks in the block
cache; if the needed block is not there it calls the device driver.
 Step 3: The device driver issue the request to the hardware and
the process will be blocked until the disk operation has been
completed
 Step 4: When the disk is finished, the hardware generates an
interrupt
 Step 5: The interrupt handler is run to discover what happened,
i.e., which device wants attention right now. It then extracts the
status form the device and wakes up the sleeping process to
finish off the I/O request and let the user process continue

28
Layers of I/O Software(cont’d)

Layers of the I/O system and the main functions of each


layer
29

You might also like