Input and Output OS view the commands the hardware accepts, how it is programmed the functions the hardware carries out the errors the hardware can report back Kinds of devices block: stores fixed-size blocks that can be individually addressed (seek) disk drive, tape drive character: delivers or accepts a stream of characters (no seeking) terminals, network card others clock: interrupts at fixed intervals Device controllers the electrical part plugged into system bus, Fig 5-1 OS "talks" to it device is electromechanical part plugged into controller disk controller reads sectors on disk, does error correction, sends blocks to OS by copying to main memory buffer IO channels small computer, a souped-up DMA chip, offload work from CPU Memory mapped IO no separate IO instructions, instead the controller registers are mapped into an area of main memory OS writes controller commands and parameters into this memory after interrupt, OS reads back status and error codes read, write, seek, format, recalibrate DMA controller given (command, memory address, count) controller copies block of count bytes from its buffer to memory address then generates interrupt, Fig 5-3 Desirable features of IO software a uniform, device-independent naming scheme for specifying files stored on block devices and for accessing devices directly a uniform, device-independent mechanism for programs to open, read, write, and close files and devices detect and handle errors as close to hardware as possible make IO system calls (from user) block (be synchronous) even though OS itself does IO asynchronously (interrupt-driven) handle and coordinate shared versus dedicated device allocation IO software layers, Fig 5-6 interrupt handlers OS gets system call, blocks process, sends command to controller, later controller interrupts, process is unblocked device drivers (device-dependent) write commands to controllers, read status and error reports back knows about sectors, tracks, cylinders, platters, 8E1 vs 7N1 translates "read block n from unit k" to (sector,track,surface) issues seek command, blocks waiting for interrupt device-independent IO software, Fig 5-5 uniform interface to device drivers device naming in UNIX /dev/tty0 i-node contains character special file type and major and minor device numbers device protection device-independent block size group hardware sectors together into logical block buffering gather user IO into blocks, hold user type-ahead storage allocation on block devices free list or bit map of free blocks dedicated device management, allocate and release open exclusive system call error reporting user-space IO software standard IO library linked into user program, e.g. printf line printer spooling daemon disks seek (disk arm) scheduling, done since this is dominant component time to read information off a disk = seek time (10-30ms) + rotational delay (5-10ms) + transfer time (track per revolution e.g. 16KB in 16ms) to read one 512B sector from a disk with 32 sectors per track is 20ms + 8ms + 0.5ms FCFS: fair SSTF: pick closest cylinder to seek to next from the queue of outstanding requests, reduces average service time, but starvation possible, large variance in service times, Fig 5-7 SCAN (elevator): handle all requests in one direction, then reverse and handle all requests in other direction, not as small average service time but smaller variance, Fig 5-8 C-SCAN: handle requests only when going in one direction, when reach last outstanding request issue one seek to the other end, smaller variance than SCAN at each cylinder, handle requests as their sectors pass under the read-write heads (rotational sensing) track-at-a-time caching can be done by the driver in main memory or the controller in its own memory clocks generate periodic interrupts clock software device driver does following on each interrupt time of day CPU usage: decrement time quantum counter at every clock tick, when counter reaches zero, do a context switch, add time quantum to total CPU time used by process (accounting) alarms: signal process a certain amount of time in future, Fig 5-12 watchdog timers: alarms internal to the OS, instead of sending a signal to a user process when the time is reached, a procedure inside the OS is called terminals, Fig 5-13 serial RS-232, Fig 5-14 UART converts bytes to bit-serial over RS-232 line and back 9600 bps is 1ms per character, so terminal driver is interrupt driven (do something else while character coming or going) some terminal controllers can do DMA on output and have a silo to contain input (device driver will poll silo periodically but controller will generate an interrupt if silo gets close to full) memory-mapped, Fig 5-15, 5-16 VRAM is mapped into main memory address space to write to screen, CPU writes to VRAM (can write a whole screen in a few ms) VRAM can hold characters (video controller has a pixel map for each character in ROM) or VRAM can be bit-mapped for multiple fonts and general graphics keyboard generates an interrupt when each key is pressed (sometimes when released, too) raw mode: character-oriented, driver does no intraline editing cooked mode: line oriented, driver makes available a whole line after user intraline editing applied keyboard interrupt handler puts typed characters into a buffer for the terminal until requested by process, Fig 5-17 buffer can be inside the terminal line data structure (say 256 chars max) or can be a chain of smaller buffers drawn from a common pool driver does echoing to output, if turned on output software RS-232: buffer pool for not yet displayed characters