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