Lecture 38

I/O Devices

The crux

How should I/O be integrated into systems?

What are the general mechanisms?

How can we make the efficiently?

Prototypical System Architecture

• CPU is attached to the main memory of the system via some kind of memory bus

• Some devices are connected to the system via a general I/O bus

I/O Architecture

• Buses
  • Data paths that provided to enable information between CPUs RAM and I/O devices
• I/O bus
  • Data path that connects a CPU to an I/O device
  • I/O bus is connected to I/O device by three hardware components: I/O ports interfaces and device controllers

Canonical Device

• HW interface: allows the system software to control its operation
• Internals: implementation specific

Canonical protocol

while  STATUS == BUSY
; //wait until device is not busy
write data to data register
write command to command register
  (Doing so starts the device and executes the command)
while  STATUS == BUSY
; //wait until device is done with your request

• OS waits until the device is ready by repeatedly reading the status register aka Polling

Crux 2

How to avoid the costs of polling?

How can the OS check device status without frequent polling, and thus lower the CPU overhead required to manage the device?

Interrupts

• Put the process requesting I/O to sleep and context switch
• When I/O is done, wake the waiting/sleeping process by an interrupt

Crux 3: How to lower PIO overheads

What is PIO?

With PIO, the CPU spends too much time moving data to and from devices by hand. How can we offload this work and thus allow the CPU
to be more effectively utilized?

DMA (Direct Memory Access)

• A DMA engine is essentially a very specific device within a system that can orchestrate transfers between devices and main memory without much CPU intervention

When completed DMA raises an interrupt I/O begins on Disk

Polling vs interrupts vs DMA

Polling

Intterupt

CPU copies data from memory to device

DMA

Crux 4: How to communicate with devices

How should the HW communicate with a device? 

Should there be explicit instructions? 

Or are there other ways to do it?

Two methods

• I/O instructions: a way for the OS to send data to specific device registers
  • in and out instructions on x86
  • Privleged stuff
• Memory-mapped I/O
  • Device registers available as if they were memory locations
  • The OS load to read or store to write to the device instead of main memory
  • HW then routes the load/store to the device

Crux 5

How to build a device-neutral OS

How can we keep most of the OS device-neutral, thus hiding the details of device interactions from major OS subsystems?

File system abstraction

• OS has to interact with different HW interfaces, e.g., SCSI disk, IDE disk, USB drives, etc
• Device driver
  • any specifics of device interaction are encapsulated within DD

File system stack

• Raw interface: directly read/write blocks w/o FSI
• Downside to FSI: specific device capabilities cannot be used

LOC

According to cloc run against 3.13, Linux is about 12 million lines of code.

• 7 million LOC in drivers/
• 2 million LOC in arch/
• only 139 thousand LOC in kernel/

Ref: https://unix.stackexchange.com/questions/223746/why-is-the-linux-kernel-15-million-lines-of-code

Problems with top 2 million?

• Amateurs write device drives \(\Rightarrow\) bugs
• Device-specific abilities unusable