28 January 2002 Operating Systems Interrupts and Device Drivers ------------------ Interrupts Simple model: interrupt request line, CPU senses after executing each instruction when detected, if interrupt detected, save what you were doing, jump to interrupt handler routine, which determines what caused the interrupt, then process correct interrupt, then return. Slightly more fancy than a single interrupt handler and a single request line is to have each device interrupt with a unique (or semi-unique) interrupt request value. You can see the IRQ setting for your devices, even under windows. Go to the System Properties, Device manager, choose a device, and look at its resources. On my machine: mouse=12, Network card=9, keyboard=1. IRQ values are an efficient mechanism to determine which device raised the interrupt, and therefore which interrupt handler should be executed. If an interrupt handler is interrupted, then we can queue the rest of the interrupt processing for later. Need to make sure that the processing of this queue has higher priority than user processes. Interrupt handlers can be interrupted by either the same device, or a different device. To prevent same device from interrupting, delay telling the device that the interrupt has been processed. Only when another interrupt can be handled should the device be notified. Cannot do this for the same devie. Instead, use the queuing mechanism earlier to defer the remainder of the processing of the first interrupt handler. Because there may be multiple processes waiting for multiple devices, we have to keep track of all of this so that we know which processes to resume to. This is done with the device-status table. Keep the device type, the device address, device status, and if busy: the type of request and parameters. Can also have a wait queue per device to allow processes to wait for the device to become available. After an interrupt is processed, the wait queue for that device is checked to see if there are waiting processes. An additional complication: modern processors do not process a single instruction at a time. Instead they pipeline the instructions, and some processes even execute operations out of order. All of this makes it more difficult to suspend a process when an interrupt occurs because we need to know how to restart the process later. Can't just look at the PC. precise interrupts : leave PC in well-defined state the PC is saved at a well known place all instr. before one of the PC have executed no instr beyond one of the PC has been executed execution state of the one of the PC is known imprecise interrupts: OS has to figure out what the process has and has not done. To decide this, the CPU dumps a large amount of internal state data. Can be slow to dump this much state and recover it. irony: very fast, superscalal CPUs sometimes unsuitable for real-time work because of slow interrupts. Pentuim Pro and successors are superscalar, but have precise interrupts for backward compability. Price is that the CPU is complex to handle interrupts. DEVICE MANAGEMENT -------------- memory mapped I/O processor needs to access devices traditionally, special commands input dev_addr output dev_addr copy_in cpu_register, dev_addr, controller_reg copy_out cpu_register, dev_addr, controller_reg test cpu_reg, dev_addr By putting the devices onto the same address space now, just use: load R3, addr instead of copy_in reduce the # instructions in the processor read and write the status registers instead of test/input/output Programmed I/O - direct CPU does the work of writing to the device interrupt driven or polling to decide when finished DMA user input at a 9600 baud terminal transfer one character every 1 milisecond. Well written interrupt service routine to input characters to a buffer may require 2 microseconds, leaving 998 microseconds of every 1000 microseconds for CPU computation. So, IO has a low priority interrupt, letting other IO ops be executed first. But, a high speed device, e.g., a tape, disk, communication network, can transmit close to memory speeds. if CPU needs 2 microseconds to respond to each interrupt, and interrupts arrive every 4 microseconds, not much time left over for CPU to execute. DMA is the (hardware) solution! Only one interrupt per block buffer is from 128 to 4096 bytes DMA controller operates independent from CPU DMA controller and CPU compete for access to the bus Device Drivers -------------- used by the app to request controller action constraints of devce drivers 1. API for functionality of device AND uniformity 2. correct coordination among process, driver, controller 3. optimize overall machine performance Driver API strive for device independence why? simplify user's interaction with devices simplify the OS's interaction with the drivers BSD UNIX classifications: char(kybd)/block(disks) sequential(tape,kybd)/direct(hard drive) block character close app releases device app releases device ioctl not avail pass driver specific op open prep device for app prep device for app read (see strategy) request input from dev select not avail check if read/write will succ strategy start block read/write not avail stop not avail disconctinue stream output write (see strategy) request an output op strategy allows buffering to be done inside the kernel driver specialized ops: rewind a tape, power up/down dik drive can either broaden the API OR use UNIX ioctl ioctl - driver interprets the arguments kernel interface driver is priv. needs access to memory of multiple processes can no longer recompile the os to include new driver reconfigurable device drivers - OS dynamically binds the driver functions - kernel has API used by th drivers for allocation of buffer space, for access to kernel data, etc optimization - buffering - small scale and large scale, input and output can buffer inside the device itself controller tells which data register to use can buffer inside the device driver double buffering downside: too much copying of data think about network communication buffering - e.g., printing lp (-c) option disk access - we will talk more about detail later want to optimize for head movement