IO Layers

Device Types

• Block Devices: one block of data accessible at one time | blocks independent from another (a.g., disks)
• Character Devices: operates on stream of characters
  • not addressable
  • no seek operation
  • e.g., printers, network cards, mice

Device Controller

• component of IO-Device
• conerts serial bitstream to blocks of bytes
• does error correction
• controlled via control registers

Interrupts

1. device asserts signal on bus line assigned to it
2. interrupt controller notices that, decides which interrupt is handled first
3. issues interrupt to cpu for this device | number referenceing the device in a interrupt vector is attached

Interrupt Handling

• ISR is started
  1. CPU stores machine state required to restore running process
     • can be stored in internal registers
  2. acknowledges interrupt by writing special value to interrupt controller's IO ports

Precise and Imprecise Interrupts

• Precise Interrupt: leaves machine in well-defined state
  • PC is saved
  • all and onyle the instructions bevore the one pointed to by the PC have completed
  • execution state of the instruction pointed to by the PC is known
• Imprecise Interrupt: requires much more information about internal state of CPU to guarantee successful restart
  • (-) complicated, slow
  • interrupts like fatal error can be imprecise

Programmed IO

• Umbrella term for memory mapped IO and port mapped IO
• I/O method that involves the CPU to transfer data between the host system and a peripheral device
• "programmed": the data-transfer is performed by instructions executed by the CPU
  • process is in busy wait loop while IO operation takes place
• MMIO and PMIO both use instructions to read/write addresses of the host system’s memory which are mapped to a device’s control registers in order to access the device
  • memory mapped: normal memory access instructions
  • port mapped: distinct IO operations

Interrupt-Driven IO

• process requesting IO operation is blocked while waiting for IO
  • -> Other processes can work
• when IO device completes it generates interrupt -> unblocks the waiting process

IO using DMA

• DMA issues interrupt when IO operation handled by DMA has completed

IO Software Design

• device independence: IO-access independent of particular device's type
• uniform naming: access through identifiers, independent of particular device
• error handling: transparent recovery from errors
• $\exist$ synchronous and asynchronous IO abstraction to user programmes ?
• buffering: decouple data rate of device to data rate of system

Interrupt Handlers

• when device completes operation, it raises an interrupt which will be handled by the interrupt handler

1. save registers
2. set up context for interrupt service procedure
3. set up stack for interrupt service procedure
4. acknowledge interrput controller
5. copy registers from where saved to process table
6. run interrupt service procedure
7. choose which process to run next
8. set up MMU context for process to run next
9. load new process' registers, including PSW
10. start running new process

Device Drivers

• each device controller exposes device registers for
  • issuing commands
  • read device status
• device specific code to use there registers is called the device drivers
• typically provided with the device
• typically part of the OS kernel

Role of Device Drivers

• accepts abstract read and wirte requests & performs necessary actions to complete request
• device drivers need to be reentrant
  • interruption and subsequent restart must be possible
• error handling device driver should handle termination (data transfer) gracefully

Device-Independent IO Software

• some IO software is not device specific
  • uniform interfacing for device drivers
  • buffering
  • error reporting
  • allocation, releasing dedicated devices
  • providing device-independent block size

Uniform interfacing for Device Drivers

• standardising interface of IO devices allows new devices to be added to system, with no modification needed on OS side
• for each class of device $\exist$ set of functions that device drivers must comply with#
• uniform naming of devices: device-independent software maps symbolic device name to proper device driver

IO Buffering

• unbuffered IO: each character transfer: one interrupt
• user-level buffer: works but (-) buffer can be paged out of memory :/
• kernel-level buffer: works (-) can be full, bevore copied to user-level buffer
• Double buffering: in kernel, used for handling input arriving during copy operation of filled-up buffer to userspace

User-Space IO Software

• User-space libraries: provied necessary routines for issuing IO requests
• Spooling System:
  • allows shared access to dedicated IO device
  • special process called deamon has exclusive access to IO device
  • regular process places files in spooling directory
  • deamon process will send files to the IO device