IO Software Layers

1
I/O Software Layers
Increasing Abstraction
2
Goals of I/O Software

• Device independence
• Uniform naming
• Example Unix mounts devices to special file
  names
• Error handling
• Synchronous/asynchronous I/O (blocking vs.
  non-blocking)
• I/O appears to be blocking to user programs, but
  CPU is doing other activities while I/O occurs in
  background
• Buffering data from devices does not go
  straight to main memory, but is instead stored in
  a buffer on the device

3
Interrupt Handlers

• Handles interrupts (requests for I/O)
• Does a full context switch to interrupt handler
• Unblocks device driver after I/O is done

4
Device Drivers

• Blocks itself as it waits for I/O to be completed
  and interrupt occurs
• Possible implementation of blocking
• Up/down on semaphores
• Wait for condition or message
• Includes device-specific code written by
  manufacturer
• Driver usually part of OS kernel
• Unix kernel compiled with device drivers
• Linux uses loadable modules which are chunks of
  code loaded into kernel while system is running
• Windows dynamically loaded into system at
  startup and plug-n-play

5
Device Drivers

• Functions
• Accept read/write requests from
  device-independent OS software
• Initialize device
• Manage power requirements
• Checks device status is device busy?
• Issues commands (read/write) to device and checks
  if command suceeded
• Error handling re-issue command or return error
  code to caller
• Must be reentrant driver may be called to
  handle a second interrupt while still working on
  the first
• Must be able to abort I/O without corrupting
  kernel structures

6
Device-Independent OS Software

• Boundary between device driver and
  device-independent software varies between
  systems and devices
• Typical functions
• Uniform interface for device drivers
• Buffering
• What to do when buffer fills up?
• What to do if memory buffer is paged out
• Double-buffering 2 buffers, 1 for current use
  into which user writes, 2nd to be copied to/from
  main memory after it is filled
• Error reporting
• Retry I/O or report to user with error code
• Identifies device error vs. programming error
• Allocating and releasing dedicated devices
  block and queue processes requesting devices that
  can be used by only one process at a time
• Device-independent block size hide difference
  between disks with different sector sizes or
  streaming data

7
User-level I/O (APIs)

• What API programmer wants
• Blocking and non-blocking calls
• Simple return code
• No need to buffer
• Simple, abstract definition of device no size
  limits or blocking factors
• No visible concurrent use of shared devices
• No knowledge of physical allocation
• Uniform naming
• Easy installation of new devices

8
User-level I/O (APIs)

• User-level I/O usually implemented in libraries
  linked with user programs
• Example printf, write
• User level I/O programs spooler (daemon)
• Print spooler
• Process generates file and puts in directory of
  spooler to be printed
• Only daemon has permission to use printers
  special file (mounted name)
• Network spooler
• newsgroups, mail
• Collects and transmits many messages at once

9
Device Configuration

• Sysadmins goal one OS image that can be run on
  different machines, prepared in each case for
• Different set of devices
• Different number of each device
• At different addresses (IRQ, DMA, bus)
• Non-exclusive possibilities
• Static configuration procedure performed when OS
  executable is created
• Dynamic auto-configuration at boot time
• Loadable drivers configured at run-time

10
Device Configuration Static

• When making OS image, run /usr/sbin/config with
  input file that describes
• All devices that might exist
• All addresses at which devices might be located
• /usr/sbin/config outputs Makefile, various .c
  and .h files to be compiled as part of the kernel
• With these files, kernel boots knowing all
  possible configurations

11
Device Configuration Auto-configuration

• Statically configured OS image contains device
  driver code for all possible devices, but want to
  allocate data structures only for devices that
  are present
• 2 ways to reduce useless device driver code in OS
  image
• Carefully specify minimum set of possible devices
  based on machines intended use (examples
  client vs. servers)
• Run-time loadable device drivers
• Auto-configuration performed at boot-time to
  determine which subset of devices are actually
  installed using probe and attach
• For each possible device, drivers probe routine
  is called with possible address of I/O registers
  as arguments

12
Device Configuration Auto-configuration

• probe routine
• Install special temporary interrupt vector with
  same entries in every possible slot since IRQ
  number may be unknown
• Tell controller to interrupt
• Wait for interrupt
• Fall through no interrupt means that controller
  (and hence, device) is absent
• If interrupt happens, device is present, and
  interrupt handler completes proper installation
  using attach
• attach initializes hardware and device state
• Example for disk, attach will identify geometry
  and specify partition table found at beginning of
  disk

13
Device Configuration Loadable Device Drivers

• Motivations
• Static configuration encourages over-inclusion of
  drivers (taking up a lot of space)
• Avoid reboots
• Easier device driver debugging
• Dynamic loading mechanism can be used for other
  types of modules
• At boot time, after initial configuration, place
  special routine in open slot of all major device
  numbers (names) that do not have drivers
• Special routine loads and initializes driver
• Loaded driver specifies whether to unload on
  closing of device
• If yes, special close routine is installed that
  unloads

14
Windows Plug-n-play

• Another method of boot-time device discovery
  initialization
• Includes some run-time events such as device
  insert/removal
• Combination of efforts by OS, hardware, and
  device driver
• Device driver must communicate with and is
  subordinate to OSs PnP manager
• Device requests these resources from PnP
• IRQ
• DMA channel
• I/O port
• Memory range
• Device driver supplies set of procedures for its
  services
• Device entry initializes driver
• Add device called by PnP manager for each
  device

15
Windows Plug-n-play Implementation

• Option 1 One driver can do all work by itself to
  interface with device
• Option 2 Drivers may be stacked
• Requests are passed through series of drivers,
  each doing part of the work
• Examples
• separate bus interface with device and device
  control
• Separate error-checking modules