[go: up one dir, main page]
Scribd
Upload
935 views11 pages

IO Software Layers

This document discusses different software layers involved in input/output (I/O). It describes interrupt handlers that handle hardware interrupts and unblock device drivers. It then covers the steps performed by interrupt service procedures. It also discusses device drivers, which control specific I/O devices, and how they initialize devices, handle interrupts, issue commands, check for errors, and return status. Finally, it mentions writing reentrant driver code and device-independent I/O software.

Uploaded by

Vidya Sisale
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
935 views11 pages

IO Software Layers

This document discusses different software layers involved in input/output (I/O). It describes interrupt handlers that handle hardware interrupts and unblock device drivers. It then covers the steps performed by interrupt service procedures. It also discusses device drivers, which control specific I/O devices, and how they initialize devices, handle interrupts, issue commands, check for errors, and return status. Finally, it mentions writing reentrant driver code and device-independent I/O software.

Uploaded by

Vidya Sisale
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/ 11

I/O Software Layers

Possible organization of software layers. Each layer would


have a well-defined interface to adjacent layers. The details
of each layer would be hidden though to the other layers
Interrupt Handlers
 Interrupt handlers are best hidden
 have driver starting an I/O operation block
until interrupt notifies of completion
 Interrupt procedure does its task
 then unblocks driver that started it
Interrupt Handlers (cont.)
 Steps that must be performed in software
after interrupt completed (differs from
processor to processor)
1. Save regs not already saved by interrupt hardware
2. Set up context for interrupt service procedure. Setting up
TLB, MMU and a page table.
3. Set up stack for interrupt service procedure
4. Ack interrupt controller, reenable interrupts
5. Copy registers from where saved
6. Run service procedure
7. Set up MMU context for process to run next
8. Load new process' registers
9. Start running the new process
Device Drivers
 We have to have device specific code for
controlling every I/O device.
 This device code is called a device driver.
 Usually device drivers are part of an OS’s
kernel, but it depends on the design of the
system.
 Obviously the driver must have access to
hardware registers for the I/O device it is
controlling. If the driver is not part of the
kernel it will need to issue system calls.
Logical Positioning of drivers
What does a device driver
actually do?
 Initialize the device. (May include
powering up the device)
 Perform any operating system calls that
may be necessary for interrupt
handling.
 Checks input parameters for validity (Is
it a valid command to the device?)
 Check if the device is in use.
What does a device driver
actually do? (cont.)
 Controlling the device by issuing
commands to the device controller
registers
 Wait for the commands to be performed
(driver may block (go to sleep) and wait
for an interrupt).
 Check for any errors and perform any
error handling or logging
What does a device driver
actually do? (cont.)
 Returns status information to the caller
and services any waiting requests or
blocks.
Writing Reentrant Driver Code
 We should write driver code so that if
the execution of the driver code is
interrupted so that it is called a second
time before the first call is completed
there isn’t any shared data corruption.
Recipe for writing reentrant
functions
 It uses all shared variables in an
atomic way, unless each is allocated to
a specific instance of the function.
 It does not call non-reentrant
functions.
 It does not use the hardware in a non-
atomic way.
Device Independent I/O
Software
 Uniform interfacing for device drivers
 Buffering
 Error reporting
 Allocating and releasing dedicated
devices
 Providing a device-independent block
size

You might also like