------------------------------------------------------ Lecture 13 - March 03, 2003 ------------------------------------------------------ AGENDA: 0 Admin 1 Ch 3.1: Principles of I/O hardware 2 Ch 3.2: Principles of I/O software ------------------------------------------------------ 0 - ADMIN ------------------------------------------------------ Startout Q: How does a task/device driver learn that a relevant interrupt has arrived for it? Wednesday: * RI #4 (there was no official RI last week) Friday: * HM #4 (problems TBA) ------------------------------------------------------ 1 - CH 3.1 PRINCIPLES OF I/O HARDWARE ------------------------------------------------------ TWO CATEGORIES OF DEVICES * block devices - store info in fixed-size blocks. Essential property is that each block is individually addressable. - hard disks, floppy disks - Not a perfect definition: tape devices are not really random/arbitrary access devices. * character devices - delivers or accepts data stream, no concept of block structure. Not addressable, no meaninful seek operation. - printers, network interface, mouse, keyboard * Some things don't fit: e.g. clock, memory-mapped scrn * overall useful device classification system * file system uses just block devices DEVICE CONTROLLERS * controller + attached devices * O/S really deals with controller, not storage device * I/O channels: multiple buses with specialized assistant deputy CPUs to offload I/O work from main CPU set. - e.g. DEC System-20 family * Data stored on disk like a network packet - preamble, data (512 bytes typical), ECC. - preamble contains cylinder & sector #, size and other info (quick waving of hands. :-) * controller converts data stream from disk into block and verifies block integrity * CRT controller Device control registers * each controller has registers that are used for communicating with the CPU. - can be in regular memory address space (memory-mapped I/O) - can have separate address space (I/O space) * coordinating info with CPU. Set status info in registers and then 1) use an interrupt to tell CPU that ok to look - CPU doesn't bother to check until told ok 2) set a flag in a register to tell CPU that ok - requires CPU to come look every so often INTERRUPTS * Pentium-class has 15 interrupts available * fig 3-2 p. 157 * MINIX does not map IRQs to same interrupt vectors DMA - DIRECT MEMORY ACCESS * When data is ready on controller, CPU has to read it a chunk (byte/word/other) at a time from the controller's buffer. Wasting CPU time. * With DMA, CPU also tells controller memory address where data is to go and a byte count, and then CPU wanders off to do the important things that CPUs do. * Meanwhile DMA is carried out (by device controller, or perhaps special DMA controller) until the right number of bytes have been copied, then interrupts CPU * Two-step buffering process 1) device to controller 2) controller to memory * Simple devices can't handle reading a block while dealing with incoming requests. => fig 3-4 interleaving * DMA sometimes slower than CPU-direct control, and makes systems more expensive. ------------------------------------------------------ 2 - CH 3.2 PRINCIPLES OF I/O SOFTWARE ------------------------------------------------------ Think layers-r-us GOALS * device-independence - code in layers above bottom one should be able to do I/O same way, without having to modify code to work with different devices. * uniform naming - actual device name should not be tied to device in any way. - can tie devices into transparent file system and use without knowing any hardware/location specifics - contrast MS-WIN w/ A:, C:, etc. * error handling - should be handled as close to hardware as possible. the higher up you get, harder to try fixing. upper layers should only be informed if lower layer fails. - very like networking architecture * synchronous vs. asynchronous I/O - synchronous I/O much easier on programmers * sharable vs. dedicated devices - ok to share hard disk & mingle I/O requests - doesn't work so well with printers or tape drives I/O hierarchy 4) User-level software 3) Device-independent O/S software 2) Device drivers 1) Interrupt handlers INTERRUPT HANDLERS * hide from rest of software * do something like receive() and block - system then does send() to wake it up DEVICE DRIVERS * All device-specific code goes here - no device-specific code above this level. * Try to have one device driver per device type, or set of closely related devices. * device driver accepts abstract requests from device-independent software layer above and then executes the request in device-specific terms. * device may then block to wait for interrupt DEVICE-INDEPENDENT I/O SOFTWARE * most I/O software is device-independent * sometimes push stuff down to layer 2 for efficiency reasons * functions of device-independent I/O software fig 3-5 p. 163 * major & minor device numbers - major specifies device driver - minor specifies particular unit * permissions - many small systems have no control - UNIX uses standard permissions bits * hides underlying sector/chunk sizes - provide uniform block size to higher layers * buffering - for performance and because block devices must be accessed by the block, but USER-SPACE I/O SOFTWARE * read() and write() are the low-level primitives - everything else is built on top - the thing to use if high-performance I/O is needed * spooling - queuing up requests, e.g. email, printer See fig 3-6 p. 166 COS 421 - Lecture Notes #13 SPRING 2003 COS421-lect-2003-03-03.doc Page 1 Printed 03.03.03