Device Management – I/O Architecture, Drivers, Scheduling, Buffering & RAID

1. Introduction to Device Management

Device management is the OS subsystem that controls all hardware peripherals, from keyboards and printers to magnetic disks and network cards. Its primary responsibilities are

1. Abstracting hardware details so that applications can request I/O without knowing device specifics.
2. Coordinating access to shared devices, preventing conflicts and ensuring fairness.
3. Optimising performance by selecting appropriate I/O techniques, buffering strategies, and scheduling policies.

The device manager works closely with the kernel, file system, and process scheduler. It receives I/O requests from processes (via system calls such as read, write, open), translates them into device‑specific commands, and monitors completion.

---

2. I/O Hardware and Interfaces

2.1 Basic Components

2.2 Bus Architectures

• ISA / PCI / PCI‑Express: Provide address and data lines, support plug‑and‑play enumeration, and allow devices to generate interrupts or DMA requests.
• USB / FireWire: Serial bus with hot‑plug capability, using a host controller driver to manage multiple endpoints.

Understanding the bus is essential because the OS must configure address spaces, IRQ lines, and DMA channels during boot‑time device discovery.

---

3. I/O Techniques

Three classic techniques are used to move data between the CPU and a device.

3.1 Worked Example: Interrupt‑Driven Keyboard Input

Assume a process calls read(fd, &c, 1) to obtain a single character from the keyboard. The trace below shows the interaction between the process, OS, and hardware.

Process                OS Kernel                Keyboard Controller
   |                       |                               |
   |--- read(fd, &c,1) --> |                               |
   |                       |--- check buffer (empty) ----> |
   |                       |<--- buffer empty, block ---- |
   |                       |--- enable IRQ for keyboard -->|
   |                       |                               |
   |   (process blocked)   |                               |
   |                       |                               |
   |<--- IRQ arrives (key press) ------------------------|
   |                       |--- ISR: read scan code -----> |
   |                       |--- translate to ASCII -----> |
   |                       |--- place char in buffer ----|
   |                       |--- wake up blocked process -|
   |--- return char c ---> |                               |
   |                       |                               |

Key points: the CPU is free to run other processes while the keyboard controller waits for a key press. The ISR (Interrupt Service Routine) performs minimal work—reading the scan code, converting it, and waking the blocked process.

---

4. Device Drivers

A device driver is a kernel module that implements a standard interface (open, close, read, write, ioctl) for a specific class of hardware. Drivers can be character, block, or network drivers, depending on the device type.

4.1 Driver Structure

+---------------------------+
|  Device Driver (kernel)   |
+---------------------------+
| 1. Initialization         |
| 2. Open / Close           |
| 3. Read / Write           |
| 4. IOCTL (control)        |
| 5. Interrupt handler      |
| 6. DMA setup (if needed) |
| 7. Cleanup / Unload       |
+---------------------------+

• Initialization: Detect hardware, allocate resources (I/O ports, IRQ, DMA channel), register the device node (/dev/sda).
• Open/Close: Manage reference counts, enforce exclusive access if required.
• Read/Write: Translate generic requests into device‑specific commands; may invoke DMA or issue interrupts.
• IOCTL: Provide device‑specific control operations (e.g., setting baud rate on a serial port).

4.2 Driver Models

4.3 Error Handling & Recovery

Drivers must detect hardware faults (e.g., CRC errors, timeout) and propagate them to the OS via error codes (EIO, ENODEV). Recovery strategies include retry, reset, or mark device offline.

---

5. Device Allocation, Buffering & Spooling

5.1 Allocation Policies

1. Pre‑allocation (static) – Resources assigned at boot; simple but inflexible.
2. Dynamic allocation – Resources granted on demand; uses data structures like free lists for IRQs, DMA channels, and I/O ports.

The OS maintains a device control block (DCB) for each device, storing its state, allocation status, and pending I/O queues.

5.2 Buffering Techniques

Worked Example: Circular Buffer for a Serial Port

Assume a circular buffer of size 8 bytes. The ISR writes incoming bytes at head, the user process reads from tail.

Initial: head = 0, tail = 0, buffer empty
ISR receives byte 'A':
   buffer[head] = 'A'   // buffer[0] = 'A'
   head = (head + 1) % 8 = 1
Process reads:
   byte = buffer[tail]  // byte = 'A'
   tail = (tail + 1) % 8 = 1

When head == tail after a write, the buffer is full; the ISR may discard new data or overwrite oldest data based on policy.

5.3 Spooling Workflow

1. Application writes print job → OS writes to spool file on disk.
2. Spooler daemon reads the file, formats it, and sends to printer driver.
3. Printer driver uses interrupt‑driven I/O to feed data to the printer.

Spooling enables multiple users to submit jobs simultaneously while the printer processes them sequentially.

---

6. Disk Scheduling & RAID

6.1 Disk Scheduling Algorithms

Example trace (requests: 55, 58, 39, 18, 90; initial head at 50, SCAN moving upward):

Head moves: 50 → 55 → 58 → 90 → (reverse) → 39 → 18
Total movement = (55-50)+(58-55)+(90-58)+(90-39)+(39-18) = 5+3+32+51+21 = 112 cylinders

6.2 RAID Levels

Advantages/Disadvantages

• Striping (RAID‑0) gives maximum throughput but no redundancy—suitable only when data can be recreated.
• Mirroring (RAID‑1) doubles storage cost but provides instant failover; write performance suffers due to duplicate writes.
• Parity‑based (RAID‑5/6) balances capacity and reliability; write penalty arises from parity computation and extra I/O.
• Hybrid (RAID‑10) offers best of both worlds at higher cost; ideal for mission‑critical workloads.

---

7. Performance Evaluation & Metrics

Optimising device management often involves reducing interrupt overhead (e.g., using interrupt coalescing), increasing DMA block size, and choosing appropriate buffering to match device speed differences.

---

8. Security & Protection in Device Management

• Access control: Device files in /dev have Unix permissions; only authorised users may open them.
• Isolation: Modern OSes use IOMMU (Input‑Output Memory Management Unit) to prevent DMA attacks where a malicious device could write to arbitrary memory.
• Hot‑plug validation: USB devices are enumerated and may be subject to policy checks (e.g., udev rules).

---

Exam tip

• Conceptual questions often ask you to compare I/O techniques; memorise the table of Programmed I/O, Interrupt‑driven I/O, and DMA, focusing on CPU involvement and latency hiding.
• Trace questions: Practice the interrupt‑driven I/O sequence (process → OS → ISR → wake‑up) and be ready to label each step.
• Diagram/short answer: Be able to sketch a simple driver structure and label its main functions (init, open, read/write, ioctl, ISR, cleanup).
• Algorithmic problems: For disk scheduling, calculate total head movement for a given request sequence using SCAN or C‑SCAN; write the steps clearly.
• RAID: Remember the minimum number of disks, fault tolerance, and a single advantage/disadvantage for each RAID level; a quick 2‑column table in your answer earns marks.

Focus on definitions, the flow of an I/O request, and the trade‑offs between techniques—these are the high‑yield topics in Unit 6.