• ↑↓ pour naviguer
  • pour ouvrir
  • pour sélectionner
  • ⌘ ⌥ ↵ pour ouvrir dans un panneau
  • ←→ pour naviguer
  • esc pour rejeter
⌘ '
raccourcis clavier

The Problem

I/O operations involve many concerns: buffering, error handling, device-specific commands, interrupt processing. Putting all this in one place creates unmaintainable code and makes the OS dependent on hardware details.

Core Idea

I/O software is organized into four layers, each handling a specific abstraction level — from user-facing system calls down to hardware interrupt handling.

How It Works

The four layers (top to bottom):

  1. User-Level I/O Software: System calls (read(), write(), fopen()), buffering in user space
  2. Device-Independent OS Software: Naming, protection, buffering, caching, error reporting
  3. Device Drivers: Translate generic requests to device-specific commands
  4. Interrupt Handlers: Process device interrupts and signal completion
io_layers User User-Level I/O Software system calls, fopen/printf Indep Device-Independent OS Software buffering, naming, error handling User->Indep system call Driver Device Drivers translate to hardware commands Indep->Driver generic I/O request HW Hardware I/O devices Driver->HW hardware commands Int Interrupt Handlers process completion signals Int->User data/completion HW->Int interrupt

Key Properties

  • Each layer only communicates with adjacent layers
  • Device-independent layer makes all devices look uniform to applications
  • Drivers can be loaded/unloaded without changing the OS
  • Modularity enables portability across hardware platforms

Connections

Edge Cases & Gotchas

  • Too many layers can impact performance due to context switches
  • Device-independent layer must know enough about devices to do buffering correctly
  • Error handling must propagate correctly up through all layers
  • Some devices bypass layers (e.g., memory-mapped I/O)