Operating Systems Lecture Notes

20 February 2012 • The I-O Interface

---

Outline

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

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.

Two Access Patterns

• 

• 

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.

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.

---

This page last modified on 2012 February 20.