Operating Systems Lecture Notes

2014 November 11 • The I-O Subsystem

---

Outline

• The I-O interface.
  • Device characteristics.
• The I-O subsystem.
  • Operations and resources.

The Problem

• 

• What are these things hanging off the system?
  • And why are they there?
• How does the operating system deal with them?

Peripheral Devices

• Peripheral devices (or peripherals or devices) are information handlers.
• A device may be an information
  • source (keyboard), or
  • a sink (display),
  • a source and a sink (disks).
• A device may store information (tapes), or transmits it (networks).

Devices Differences

• Devices differ drastically in their characteristics.
  • Differ from each other, and from the host system.
• The differences include
  • Qualitative: input only (mouse), output only (audio), or input-output (disk).
  • Quantitative: transfer rates, capacity, reliability.
  • Ephemeral (networks) or not (printers).

Devices In A System

• 

Management Objectives

• Devices should be managed to provide:
  • Protection - devices are shared objects; they handle unshared information.
  • Convenience - devices are gnarly, varied, and always changing.
  • Efficiency - devices are bottle-necks; they are abstract.
• The central conflict - abstraction vs. control; convenience vs. efficiency

Device Management

• Provide efficient data transfer between device and system.
• I-O system organization - the device driver, the resource manager.
  • Provide interfaces - application, kernel, and device.
  • Operate the device.
  • Keep track of pending requests.
  • Enforce the resource policy.

Device Operation

• Establish data and parameters; start the operation; wait for completion; determine status; handle results; repeat
• Which does what?
  • CPU vs. device.
  • The trend is to move function from the CPU to the device.

CPU-Device Interaction

• The CPU directs the device, and possibly helps with some functions - error recovery.
• Several styles of CPU-device interaction.
  • Polling
  • Interrupts
  • Direct memory access.
  • Channel processors.

Device Register Example.

• Universal asynchronous receiver/transmitter (UART)

  

Device Register Example..

• The Line Status Register (read-only).

  

Device Register Example...

• Example (fake) code checking for parity errors.

  #define lsr_base 0x0200000000000000
  #define lsr_offset 0x14
  #define lsr_parity 0x04
  
  const int * lsr = lsr_base + lsr_offset;
  
  if ((* lsr) & lsr_parity)
    // parity error
  

Device Polling

• CPU continually tests for completion.
• Doesn’t scale well, difficult to get right, wastes the CPU.

Device Interrupts

• Interrupt-driver driven I-O - efficiently waiting for completion.
• The device informs the CPU when completed.
• Scales well, relatively easy to program, efficient CPU use.

Direct Memory Access

• Direct memory access (DMA) moves data between the device and system.
• Devices may have buffers to store data.
• The CPU can do it - expensive.
• The device can do it - needs access to memory; capable devices.

DMA Example

Memory-Mapped I-O

• How do the CPU and devices communicate?
• Special cpu instructions.
• Writing locations memory - memory-mapped I-O.

The Story So Far

The I-O Interface

Objectives

• Treat a variety of devices in a uniform way.
  • Independent of device variations, device types, and device number.
• Bring to bear the usual tricks:
  • Abstraction, make devices be more or less the same.
  • Encapsulation, implement abstractions as (semi-) independent modules.
  • Layering, provide modules as a resource to the OS and applications.

I-O Subsystem Structure

Device Drivers

• Device drivers abstract away device controller differences.
  • Among controllers for the same device, and among different devices.
• Device driver modules can be developed independently of the OS.
  • The dreaded kernel-mods or dlls.
• Alas, device drivers are standard (more or less) only to particular operating systems.

Device Characteristics

• Relevant device characteristics, carried through the abstraction, include

  Transfer unit: character-stream or block.

  Transfer pattern: random or sequential.

  Transfer predictability: synchronous or asynchronous.

  Sharing: shareable or dedicated.

  Transfer rates: low to high.

  Transfer direction: read

Information Units

• All devices can be thought of as information-block devices.
• The question is, “how big is the block?”
  • Individual characters: character devices, keyboards.
  • Whole units: memory-mapped files.
  • Intermediate: block devices, disks, networks.
• This property is easy, but perhaps expensive, to change.

Block Devices

• A block device presents the array of blocks abstraction.
• Block indexing: addressing the blocks.
  • More important for random-access devices.
  • The seek() interface method.
• Despite the abstraction, blocks are a fairly low-level resource feature.
  • Files as blocks is useful, but not representative.

Character Devices

• A character device transfers small or the smallest units of information.
• The character may or may not be addressable.
  • Character streams are usually not addressable (are sequential).
• Usually asynchronous input, if not output.
  • Keyboards, mouse, modems.

Network Devices

• A network device is an asynchronous block device.
• Tend to stress I-O interfaces.
  • Large blocks, unpredictable behavior, complex protocols.
  • The UNIX socket interface.
• Also presents a possibility for inter-process communication.
  • A bit cumbersome.

Synchronous Access

• 

• User blocks until the operation ends.

Non-Blocking Access

• 

• User polls the OS for operation status.

Asynchronous Access

• 

• The process requests the operation and then goes on independently of the I-O.

Blocking v Nonblocking I-O

• Blocking I-O moves the requesting process off the ready queue until the I-O is done.
  • Also known as synchronous I-O.
• Nonblocking I-O leaves the requesting process executable.
  • Also known as asynchronous I-O.
• Useful thread I-O is almost always non-blocking.
  • A thread blocking the host process is a loss.

The I-O Subsystem

• Besides hosting device drivers, the I-O subsystem also

  allocates: what gets access to what.

  schedules: when accesses occur.

  buffers: mismatch smoothing.

  caches: temporary general buffering.

  spools: long-term specific buffering.

  handles errors: masking or propagating.

  protects: everything from everything.

Allocation

• Device allocation determines what gets access to what.
  • This assumes I-O resources are safely tucked away in the OS.
• Policy plays a large role, but the mechanism is under study here.
  • Mainly authentication and authorization.
• Allocation seems straightforward, but there are subtleties involved.
  • Deadlock in particular.

Scheduling

• Some operation sequences work better than others.
  • Keep disk arm movements to a minimum, and directional.
• Some policies are naturally satisfied.
  • Print high priority (or small) jobs before low priority (or big) jobs.
• Blocked processes, and pending asynchronous requests.

Buffering

• A device’s transfer unit or rate may not match a process’s.
• Buffering can smooth out the differences.
  • Pick apart disk blocks to a character stream.
  • Assemble keystrokes into a line for delivery.
• Copy semantics frees up process space during asynchronous I-O.

Buffering Example

Caching

• Caching is a generalized, temporary form of buffering.
• The idea: keep recently accessed objects near at hand.
• Generalized because caches can contain many complex objects.
  • Web caches, for example.
• Temporary because caches are fixed size, and unaccessed objects should be tossed.
  • The cache ageing protocol, for example.

Spooling

• Spooling is another form of buffering.
• Spooling is crucial for virtual versions of non-sharable devices.
  • Printers are the classic example.
• Virtual tape drives perform I-O with spool files.
  • The spool files are eventually put back to tape.
  • This is similar to lazy evaluation.

Error Handling

• Device error handling is both simple and complex.
  • Simple because of standards (SCSI, ATA).
  • Complex because errors outstrip reporting capabilities.

$ eject /dev/cdrw2
eject: unable to eject, last error: 
Inappropriate ioctl for device

$ 

Protection

• Protect against abuse in both directions.
  • Malignant or misadjusted processes.
  • Device drivers running wild.
• Putting I-O devices in the OS is first-line protection.
  • Vetting I-O requests is a second-line of protection
• Not much protection in the other direction.
  • It’s expensive and complicated.

Summary

• The I-O subsystem abstracts, encapsulates, and layers device management in a operating system.
• The subsystem has interfaces with the hardware, the operation system, and application processes.

References

• KeyStone Device Universal Asynchronous Receiver/Transmitter (UART) User Guide, Texas Instruments, November 2010.

---

This page last modified on 2014 November 11.