Input and Output

Input / Output, usually abbreviated as I/O, is the part of the operating system concerned with how the OS communicates with physical devices, and how devices communicate back to the OS.

Examples of I/O devices include:

• mouse
• keyboard
• wireless controller
• microphone
• monitor / screen
• speakers
• printer
• scanner
• USB flash drive
• SSD / hard disk
• camera / webcam
• network interfaces:
  • Ethernet
  • Wi-Fi
  • cellular modem
  • Starlink or similar devices
• removable storage:
  • CD
  • DVD
  • Blu-ray
  • floppy disk

The key problem is that there are many kinds of devices, many brands, and many hardware-specific protocols.

Applications should not need to understand every possible device and its low-level protocol.

Therefore, the OS hides device-specific details behind a small number of consistent abstractions.

The OS provides a stable interface to applications.

Instead of forcing every application to know the details of every device, the OS groups devices into a few classes and provides common interfaces for each class.

The device-specific details are handled by drivers inside the kernel.

The main idea is:

Application
    |
    v
Operating System abstraction
    |
    v
Device class subsystem
    |
    v
Device driver
    |
    v
Hardware device

Character devices expose a byte stream.

Properties:

• sequential access
• no fixed block size
• usually one byte or character at a time
• no random access

Examples:

• keyboard
• mouse
• serial port
• terminal / TTY

Historically, TTY means “teletypewriter”. The name is old, but the abstraction still appears in modern operating systems.

A useful mental model is a tape-like stream: data arrives or is consumed in order.

Block devices expose fixed-size blocks.

Properties:

• random access
• fixed-size units
• suitable for storage

Examples:

• hard disk
• SSD
• optical disk

The internal mechanism can be very different, for example magnetic disk versus SSD, but the OS exposes a similar block abstraction.

Network devices send and receive packets or frames.

Properties:

• asynchronous
• packet-based rather than byte-stream or block-based
• often event-driven

Examples:

• Ethernet
• Wi-Fi
• cellular modem

A driver is device-specific kernel code.

Its job is to:

• program the device’s hardware registers
• handle interrupts from the device
• translate between the OS class abstraction and the specific hardware protocol

For example, the OS may have a general network subsystem, but a particular Wi-Fi card still needs a driver that knows how to operate that card.

A class subsystem is the common OS interface for all devices of a particular class.

Examples:

• character device subsystem
• block device subsystem
• network subsystem

The class subsystem provides a shared abstraction.

The driver bridges the gap between that abstraction and a specific device.

USB and PCI Express are not character/block/network classes.

They are I/O interconnects or transports.

That means they are ways of connecting devices to the system.

A USB device can be:

• a keyboard, i.e. character-like input
• a storage device, i.e. block device
• a network adapter, i.e. network device

Similarly, PCIe can carry different kinds of devices, such as GPUs, network cards, storage controllers, and so on.

A simplified I/O architecture looks like this:

Applications
    |
    v
Operating System
    |
    v
Device Class Subsystems
    |
    v
Drivers
    |
    v
I/O Bus
    |
    +--> Hardware Devices
    +--> Main Memory
    +--> CPU

The I/O bus connects the CPU, memory, and devices.

Examples of I/O buses or interconnects:

• PCI
• PCI Express
• ISA
• USB

ISA is an older IBM PC bus and is mostly historical.

The I/O bus has two main functions:

The OS controls devices through device registers.

A device exposes a small set of registers to the OS.

The driver reads and writes these registers to control the device.

Common register types:

The CPU writes to the command register to start an operation.

Examples:

• read this sector
• write this data
• reset the device
• configure the device

The CPU reads the status register to determine the device state.

It can indicate:

• device ready
• operation completed
• error occurred
• data available

For PIO, the data register may carry one word or byte of payload per access.

For DMA, the device usually gets a memory address, length, and direction, rather than transferring every byte through a data register.

The interrupt-enable register tells the device which events are allowed to generate interrupts.

For example, a keyboard driver may configure the device to interrupt the CPU whenever a key is pressed.

The mechanisms discussed in this lecture all build on these device registers:

• synchronous programmed I/O
• interrupts
• DMA

The driver interacts with the device by reading and writing these registers.

Programmed I/O, abbreviated PIO, means the CPU directly performs device register accesses.

The CPU drives the I/O operation by reading and writing registers.

PIO can be implemented in two main ways:

• port I/O
• memory-mapped I/O

Port I/O uses special CPU instructions to access a separate I/O address space.

On x86, typical instructions include:

• inb
• outb

Example idea:

inb(port)   -> read one byte from I/O port
outb(port)  -> write one byte to I/O port

This is a legacy x86 mechanism, but some devices still use it.

Memory-mapped I/O, abbreviated MMIO, places device registers into the physical address space.

The CPU accesses device registers using normal load and store instructions.

Important distinction:

• the CPU instruction looks like a normal memory access
• but the access goes to the device, not normal RAM

MMIO regions are usually mapped as uncached and order-sensitive.

This matters because device register operations often have side effects, and the CPU must not freely reorder or cache them like normal memory.

I/O devices are often extremely slow compared with the CPU.

For example:

• a human typing on a keyboard produces only a few events per second
• a CPU can execute billions of cycles per second

If the CPU waits in a loop for a device, most CPU cycles are wasted.

Synchronous PIO means the OS issues a command and then repeatedly polls the device status register until the operation completes.

The sequence is:

1. The OS writes command registers to issue a request.
2. The device performs the operation.
3. The kernel repeatedly reads the status register.
4. When the device is ready or done, the kernel reads or writes the data.
5. Data is transferred word-by-word or byte-by-byte by the CPU.

Polling means repeatedly asking the device:

Are you done?
Are you done?
Are you done?
...

In code, this is often a loop that checks a status bit.

This is also called busy waiting because the CPU is actively executing instructions while waiting.

UART stands for Universal Asynchronous Receiver / Transmitter.

It is hardware for sending and receiving serial bytes.

The serial driver talks to the UART through a few registers.

The CPU waits until a status bit changes.

Every byte costs CPU time.

This can be acceptable for tiny transfers or simple early-boot code, but it is inefficient for larger transfers or slow devices.

Advantages:

• simple to implement
• little hardware support required
• low overhead if the device is already ready
• good enough for very small transfers
• historically common

Disadvantages:

• busy waiting wastes CPU cycles
• CPU cannot do useful work while spinning
• CPU must move every byte or word itself
• large transfers burn a lot of CPU time

The problem with polling is that the CPU has to actively check whether the device is done.

Interrupts solve this by letting the device notify the CPU.

Instead of the CPU repeatedly asking:

Are you done yet?

the device says:

I need attention now.

An interrupt is an asynchronous notification from a device to the CPU/OS.

It tells the OS that the device needs attention.

Reasons for an interrupt include:

• operation completed
• device ready
• new input arrived
• error occurred

The CPU can do other work while the device is busy.

For example:

• run another process
• perform computation
• schedule other I/O
• manage other devices

The CPU no longer needs to waste time in a polling loop.

The interrupt path is approximately:

Device raises interrupt
    |
    v
Interrupt controller routes it to a CPU and vector number
    |
    v
CPU enters kernel mode through the IDT
    |
    v
OS dispatches to registered driver handler
    |
    v
Handler acknowledges device/controller and processes or defers work

The interrupt controller receives interrupt signals from devices and routes them to a CPU.

It also associates the interrupt with a vector number.

The vector number helps the CPU/OS find the correct handler.

On x86-like systems, the CPU uses the Interrupt Descriptor Table, or IDT, to enter the correct kernel entry point.

The CPU interrupts normal execution, saves state, and enters kernel mode.

The OS dispatches the interrupt to the corresponding driver handler.

The handler must usually:

• determine what happened
• acknowledge the device
• acknowledge the interrupt controller
• schedule further work if needed

If the handler does not acknowledge the interrupt properly, the interrupt may keep firing.

An interrupt can arrive while the CPU is executing unrelated code.

Example:

• a user process is computing something
• a keyboard event or disk completion occurs
• the CPU stops the current execution path
• the kernel interrupt handler runs
• later the original execution resumes

Interrupt handlers should not do too much work.

Reasons:

• they increase interrupt latency
• other devices may have to wait
• device buffers may overflow
• packets may be dropped
• keystrokes may be lost
• edge-triggered events may be missed
• level-triggered devices may keep reasserting the interrupt
• interrupt context cannot block

Interrupt handlers run in a special context.

They generally cannot sleep or block.

This restricts synchronization.

For example, an interrupt handler cannot simply wait on a normal blocking lock if the lock is unavailable.

This is why interrupt handlers should do only the urgent part of the work.

Because interrupt handlers should be short, the OS often splits interrupt handling into two parts:

• top half
• bottom half

The basic principle is:

Do the urgent minimum now.
Defer the expensive work until later.

The top half runs in interrupt context.

It cannot sleep.

It should do only urgent work.

Typical responsibilities:

• acknowledge the device
• acknowledge the interrupt controller
• record what happened
• schedule deferred work

The top half is on the critical path of interrupt handling.

Therefore, it must be fast.

The bottom half runs later.

It performs the more expensive or less urgent work.

Typical responsibilities:

• drain buffers
• complete requests
• wake waiting threads
• perform follow-up processing
• hand data to higher-level kernel subsystems

Depending on the OS mechanism, bottom halves may or may not be allowed to sleep.

Linux examples:

• softirqs
• tasklets
• workqueues
• threaded IRQs

Windows example:

• Deferred Procedure Calls, abbreviated DPCs

Important distinction:

• softirqs and tasklets still cannot sleep
• workqueues and threaded IRQs run in process context and may block

Instead of spinning until the UART is ready, the driver can enqueue data and return.

Later, when the UART is ready, it raises an interrupt.

The interrupt handler drains queued bytes into the UART.

Conceptually:

void serial_putc(uint8_t byte) {
    intq_putc(&txq, byte);
    outb(IER_REG, inb(IER_REG) | IER_XMIT);
}

Meaning:

• put the byte into a transmit queue
• enable the transmit-empty interrupt
• return immediately

The CPU does not wait for the UART to become ready.

Conceptually:

void serial_interrupt(void) {
    while (!intq_empty(&txq) &&
           (inb(LSR_REG) & LSR_THRE) != 0) {
        outb(THR_REG, intq_getc(&txq));
    }

    uint8_t ier = inb(IER_REG);

    if (intq_empty(&txq))
        ier &= ~IER_XMIT;
    else
        ier |= IER_XMIT;

    outb(IER_REG, ier);
}

Meaning:

• while the UART can accept bytes and the queue is non-empty:
  • send bytes from the queue
• if the queue is empty:
  • disable transmit interrupts
• otherwise:
  • keep transmit interrupts enabled

The caller returns quickly after enqueueing the byte.

The interrupt handler sends the data when the hardware is ready.

This removes busy waiting, but the CPU is still involved in moving each byte.

IDE stands for Integrated Drive Electronics.

It is a classic parallel disk interface.

With PIO and interrupts, the CPU no longer waits by polling, but it still copies the sector data itself.

Conceptually:

int ide_read(uint64_t sec_no) {
    setup_lba(c, sec_no);
    outb(reg_command(c), CMD_READ_SECTOR_RETRY);
    sema_down(&sector_sema);
    return 0;
}

Meaning:

1. Program the sector number.
2. Issue a read command.
3. Block the requesting thread on a semaphore.
4. Wait until the disk interrupt wakes the thread.

Conceptually:

void ide_interrupt(void) {
    uint16_t *buf = (uint16_t *) sector_buffer;

    for (int i = 0; i < SECTOR_SIZE / 2; i++)
        buf[i] = inw(reg_data(c));

    sema_up(&sector_sema);
}

Meaning:

• the disk interrupt fires when data is ready
• the CPU copies the data from the device data register into memory
• for a 512-byte sector, the CPU copies 256 16-bit words
• after copying, the handler wakes the waiting thread

Interrupts remove waiting.

But the CPU still performs the data copy.

So PIO with interrupts solves one problem but not all of them.

Advantages:

• asynchronous operation
• CPU can do other work while the device is busy
• no busy waiting
• useful for slow devices and small transfers

Disadvantages:

• CPU still copies data word-by-word or byte-by-byte
• large transfers still consume CPU time
• each request has interrupt overhead
• if interrupts happen very frequently, interrupt processing itself can become expensive

Interrupts remove the waiting cost.

They do not remove the copying cost.

This motivates DMA.

With PIO, even interrupt-driven PIO, the CPU still copies data between the device and memory.

For large transfers, this wastes:

• CPU cycles
• memory bandwidth
• interrupt-handler time

DMA solves this by letting the device move data directly.

Direct Memory Access, abbreviated DMA, means the device reads from or writes to main memory directly.

The CPU does not copy the payload.

Instead, the CPU only manages the I/O operation.

A typical DMA operation:

1. The driver prepares a memory buffer.
2. The driver maps the buffer for DMA and obtains a device-visible bus address.
3. The driver programs the device with:
   • address
   • length
   • direction
   • command
4. The requesting thread may block.
5. The CPU runs other work.
6. The device transfers data directly to or from memory.
7. The device raises a completion interrupt.
8. The interrupt handler wakes the waiting thread.
9. The driver unmaps the DMA buffer.

The CPU manages I/O, but does not copy the data.

The CPU is responsible for:

• validating the request
• setting up the DMA mapping
• programming the device
• handling completion
• waking the caller
• cleaning up the mapping

The device performs the payload movement itself.

For example, a disk controller can write data directly into a memory buffer.

A GPU can use its DMA engine to move data between GPU/device memory and main memory.

Modern GPUs are connected over PCI Express.

The CPU programs a transfer.

Then the GPU’s DMA engine can read and write main memory directly while the CPU continues executing other work.

This is important for:

• rendering
• compute acceleration
• machine learning workloads
• high-throughput data transfer

The lecture briefly connected DMA to memory-mapped files.

A memory-mapped file maps part of a file into a process’s virtual address space.

Instead of explicitly calling read/write for every access, the program can access the file through memory loads and stores.

On a page fault or page-cache miss:

1. The process accesses a mapped page.
2. The page is not currently in memory.
3. The kernel issues block I/O.
4. The storage controller typically uses DMA to load the data into the page-cache page.
5. The process can then continue.

Dirty pages can later be written back to storage, also typically using DMA.

The important idea is that DMA lets the storage device move the file data directly into the relevant memory page, rather than requiring the CPU to manually copy every byte.

A device does not necessarily use the same kind of address as the CPU.

The driver often maps a buffer to obtain a bus address, also called a DMA address.

This is the address that the device can use.

The CPU may see:

• virtual addresses
• physical addresses

The device may see:

• bus addresses
• I/O virtual addresses, depending on whether an IOMMU is used

Conceptually:

int ide_dma_read(uint64_t sec_no) {
    dma_addr_t dma = dma_map(sector_buffer,
                             SECTOR_SIZE,
                             DMA_FROM_DEVICE);

    setup_lba(c, sec_no);
    out_dma_addr(reg_dma_addr(c), dma);
    outl(reg_dma_len(c), SECTOR_SIZE);
    outb(reg_command(c), CMD_READ_DMA);

    sema_down(&sector_sema);

    dma_unmap(dma, SECTOR_SIZE, DMA_FROM_DEVICE);
    return 0;
}

Meaning:

1. Map the sector buffer for DMA.
2. Obtain a DMA/bus address.
3. Program the sector number.
4. Program the DMA address.
5. Program the transfer length.
6. Issue the DMA read command.
7. Block until the interrupt arrives.
8. Unmap the buffer after completion.

Conceptually:

void ide_interrupt(void) {
    sema_up(&sector_sema);
}

In the DMA version, the handler does not copy the sector.

The device has already written the data into memory.

The interrupt handler mainly wakes the waiting thread.

With DMA:

• no CPU payload copy is needed
• the interrupt handler becomes very small
• the device writes data directly into memory

The handler did not disappear, but its job became much lighter.

Advantages:

• no CPU payload copy
• simple completion interrupt handler
• scales well to large transfers
• suitable for high-throughput devices
• can use descriptor rings for many queued transfers

Disadvantages:

• setup is more complex
• buffers must be mapped for DMA
• pages may need to be pinned
• one descriptor usually fixes:
  • address
  • length
  • direction
• scatter-gather transfers need more setup
• consumes memory bandwidth
• consumes interconnect bandwidth
• cache coherence must be considered
• device failure needs timeout/error handling

Once a DMA descriptor is set up, it has a fixed address, length, and direction.

For example, a descriptor may say:

Read 4096 bytes from the device into this buffer.

Changing the target or direction requires setting up another descriptor or mapping.

Scatter-gather DMA allows a device to transfer data across multiple memory regions.

This is useful because physical memory may be fragmented.

However, it requires more setup because the driver must provide a list or ring of descriptors.

If a device fails during DMA, the expected completion interrupt may never arrive.

Then the waiting process could remain blocked forever unless the kernel has a timeout or error-handling path.

A robust driver must handle:

• timeout
• device error status
• failed transfer
• waking the caller with an error

With DMA, the device accesses memory directly.

This is good for performance, but it creates correctness and protection issues.

The kernel must be careful when telling a device where to read or write.

The OS may move pages, swap pages, or perform copy-on-write.

But a device doing DMA has been given an address to a physical frame or device-visible mapping.

If the OS moves or reuses that page while DMA is still in progress, the device may write into the wrong memory.

Therefore, pages used for DMA often need to be pinned for the duration of the transfer.

Pinning means:

Do not move, swap, or reuse this page while the device may access it.

Some devices cannot address all physical memory.

Example:

• a 32-bit device may not be able to address memory above 4 GB
• the machine may have much more memory than that

In such cases, the OS can use a bounce buffer.

A bounce buffer is an intermediate buffer located in memory that the device can access.

Flow:

Original buffer <--> Bounce buffer <--> Device

This solves addressability problems but adds an extra copy.

The CPU sees memory through caches.

A DMA device accesses physical memory directly.

This can create stale-data problems.

Examples:

• CPU has modified data in cache, but device reads old data from memory
• device writes new data to memory, but CPU reads old cached data

On cache-coherent platforms, hardware keeps this consistent.

On non-cache-coherent platforms, the OS/driver must explicitly:

• flush caches before device reads
• invalidate caches after device writes
• perform required synchronization

Normal CPU memory protection uses:

• page tables
• privilege rings
• permission bits
• user/kernel separation
• mechanisms such as SMEP/SMAP on some CPUs

But a DMA-capable device does not necessarily go through the CPU’s MMU.

Therefore, without additional protection, a device may be able to access physical memory directly.

A buggy driver, compromised peripheral, or malicious firmware could potentially read or write sensitive memory.

Sensitive data in RAM may include:

• kernel memory
• memory of other processes
• disk encryption keys
• login screen data
• credentials
• private application data

Hot-plug interfaces expose the system bus to devices that may be attached after boot.

Examples:

• Thunderbolt
• external PCIe-like interfaces

Historically, attacks such as PCILeech and Thunderclap demonstrated that malicious DMA-capable devices can be dangerous.

The key lesson is:

The CPU's protection model alone is not enough to protect against DMA.

Because DMA can bypass normal CPU page-table protection, systems use an IOMMU.

IOMMU stands for Input/Output Memory Management Unit.

It provides address translation and protection for device memory accesses.

The MMU protects memory accesses made by CPU processes.

The IOMMU protects memory accesses made by devices.

Analogy:

The IOMMU is to devices what the MMU is to processes.

There are three relevant address spaces:

An IOMMU can provide:

• per-device page tables
• address translation
• permission checking
• isolation between devices
• prevention of unauthorized DMA
• faulting on invalid device accesses
• ability to present scattered physical pages as contiguous I/O virtual ranges

The IOMMU only protects memory if configured correctly.

Problems can still happen.

Best for:

• already-ready devices
• tiny transfers
• simple devices
• early boot
• simple serial console usage

Cost:

• busy waiting
• CPU moves every byte
• poor for large transfers

Best for:

• slow devices
• small transfers
• keyboards
• UART / serial ports
• cases where waiting is expensive but copying is acceptable

Cost:

• CPU still copies data
• interrupt overhead per request

Best for:

• large transfers
• high-throughput devices
• disks
• SSDs
• network cards
• GPUs

Cost:

• setup complexity
• mapping complexity
• pinning
• cache coherence issues
• security issues
• completion/error handling

The simplest approach:

CPU tells device what to do.
CPU waits.
CPU copies the data.

Problem:

• CPU wastes time waiting and copying.

Improvement:

CPU tells device what to do.
CPU does other work.
Device interrupts when ready.
CPU copies the data.

Solved:

• busy waiting

Still not solved:

• CPU copying

Further improvement:

CPU tells device where the buffer is.
CPU does other work.
Device copies data directly to/from memory.
Device interrupts when done.
CPU wakes the caller.

Solved:

• busy waiting
• CPU payload copying

New problems:

• mapping
• pinning
• cache coherence
• IOMMU/security
• error handling

Input / Output: communication between the OS and physical devices.

Device-specific kernel code that controls hardware registers and handles interrupts.

A category of devices with a common OS abstraction, such as character, block, or network.

Interconnect that connects CPU, memory, and devices.

Discovery of devices and their capabilities.

Small hardware-visible control or status location used by the driver.

Programmed I/O: CPU-driven device register reads and writes.

PIO through special CPU instructions and a separate I/O address space.

Memory-mapped I/O: device registers mapped into the physical address space.

Repeatedly checking a device status register.

Actively spinning while waiting for an event.

Asynchronous signal from a device to the CPU/OS.

Interrupt request.

Interrupt Descriptor Table, used by the CPU to enter the correct kernel interrupt handler.

Fast interrupt-context part of interrupt handling.

Deferred part of interrupt handling.

Direct Memory Access: device directly reads or writes main memory.

Process of preparing a memory buffer and obtaining a device-visible address.

Address used by a device for DMA.

I/O Memory Management Unit: translates and protects device memory accesses.

Preventing a page from being moved, swapped, or reused during DMA.

Intermediate DMA-accessible buffer used when a device cannot access the real target buffer.

Ensuring CPU caches and device memory accesses see consistent data.