CMSC 421 Operating Systems Lecture Notes (c) 1993, 1996 Howard E. Motteler I/O (Chapter 5) ================= Organization of I/O Software (5.2) =================================== We can organize i/o software as a set of _layers_: | User Processes A V | Device-Independent i/o | Software A i/o requests V | reply Device Drivers | A V Interrupt Handlers | | Device Controllers A V | Hardware These layers are not always distinct in practice; e.g., in DOS we have user, DOS, BIOS, and hardware layers, with users able to bypass any of the layers and talk directly to the hardware Hardware (5.1) =============== Classification of hardware devices ----------------------------------- Block Devices - reads and writes data in fixed sized, addressable blocks - may be random access - examples: - disks (usually random access/block addressable) - mag-tape (may be block addressable, normally read and written sequentially Character Devices - read and writes a stream of characters - not block addressable - example: a terminal keyboard Other Devices - clocks; readable as a single word or set of words, or may be used to generate interrupts - bit-mapped screens; special hardware interprets values in memory as pixels 1. Hardware & Device Controllers ================================= The device controller (not device driver) interacts with the hardware at a very low level Examples: --------- (a) Disk controllers -------------------- (typical "block device") - (we already discussed low-level disk control) - translate block address to cylinder, surface, and sector - motor control and analog circuitry - error correction, bad block mapping (in newer drives) (b) Terminals ------------- There are three types of terminals - memory mapped - RS 232 (serial interface) - virtual (e.g, Xterms) Video Display (CRT) -------------------- Characters and bitmap graphics must be translated into fairly complex CRT commands. The CRT controller must: - draw lines on screen (3 beams, for color) - do horizontal retrace - do vertical retrace Bit-mapped Displays ------------------- In bit-mapped displays, special `dual ported' memory is often used, that can be both - written or read as regular memory - read by the display as pixels, with one or more bits/pixel To modify the screen one simply writes to the video ram Fonts and graphics are done in software Character Oriented Displays ---------------------------- Older character-based CRTs (VT100's, adm3a's, etc.) divided the screen into (for example) 24 x 80 character positions, and stored the state of the screen as a 24 x 80 array of bytes A fast ROM (Read Only Memory) was used to generate bit patterns for each character, and these bit patterns were concatenated in hardware char mem --> char rom --> pixel row --> shift reg --> pixels RS232 Terminals ---------------- The RS232 Terminal was typically a keyboard and character oriented display, communicating over a _serial line_ RS232 is a protocol used between many sorts of devices (e.g., 2 computers, computer & terminal, terminal & modem) (Though there are 25 pins in an RS232 connector, often just a pair of wires + ground are used) The UART takes bytes and translates them into bit streams ------| bit stream |----- UART | ------------>> | UART | <<------------ | ------| bit stream |----- terminal computer In the simplest case (no extra buffering) - 1 interrupt at each received char - 1 interrupt after each successful transmission RS232 terminals usually use a char oriented display: - smallest addressable unit is a character - may have special `graphics character sets' - may have `escape sequences' to move cursor, scroll, clear line, clear screen, etc. An "Xterm" is a virtual RS232 terminal 2. Device Drivers ================== Device drivers translate abstract, device-independent requests into device dependent operations For example, a disk driver might take requests to read or write block N of a particular device, and translate this to commands for a specific type of disk drive A disk device driver may know about the disk's - device registers - tracks, sectors, cylinders, head motion, etc. (at least before IDE and SCSI drives!) In general, the disk driver waits on either - requests (from a higher level, as a sys call) - an interrupt or message (from disk hardware) Device interaction with higher layers -------------------------------------- In general, device controllers communicate via - interrupts and interrupt vectors and either - memory addresses (for `memory mapped' i/o) or - through an `i/o bus' (as in the IBM PC) Commands, status, etc., are read through these special addresses or "device registers" (or "port addresses" if the system has a separate i/o bus) A tty for a simple system like CP/M might appear as four consecutive bytes in memory xx0: flag that screen is ready for more data xx1: data byte to screen xx2: flag that new keyboard data is ready xx3: data byte from keyboard In CP/M, a simple "polling loop" would repeatedly test xx0 and xx2, and - send next byte to screen, if screen is ready - get next byte from keyboard, if keyboard is ready In DOS (and later versions of CP/M) both screen and keyboard ready would be signaled by interrupts (Typically, the cpu will give a command, and then do something else until a device generates an interrupt) Interrupts ----------- Typical sequence of low level-events: - i/o request to device (e.g., get disk block K) - interrupt from device when request is performed (block K has been copied to buffer) It can simplify systems design to treat interrupts in the context of some existing inter-process communication model For example, a device driver might simply wait (block) for the interrupt (the i/o completion) In this case the interrupt handler could then be a very short piece of code that sends a message to the appropriate device driver Direct Memory Access (DMA) -------------------------- Basic idea: let a device "talk" directly to main memory, bypassing the CPU Most devices have buffers separate from main memory Without DMA, data would have to be transfered a byte at a time, through i/o registers to the desired buffer address With DMA, this transfer is done without going thru the CPU The device doing the transfer has exclusive access to the memory bus, during the transfer May need to resolve contention for DMA by various devices (devices may have priorities) A typical device controller might take commands of the form - a command type, e.g., sector(s) and read/write flag - a buffer address (in main memory) When the data is ready, an interrupt occurs and the controller will grab the bus and do the DMA transfer DMA may be less advantageous when CPU speeds increase in comparison to main memory speed. Example: Disk Device Driver --------------------------- (already discussed) Example: TTY and terminal drivers ---------------------------------- The tty driver for a terminal must manage both the screen and keyboard Keyboard Driver ---------------- Keyboard driver can either - pass characters on unmodified (raw) - do some local editing (cooked) The `local editing' can get rather complex - backspacing, deleting words and lines - expanding tabs - wrapping lines With local editing, the system may be interrupted only once for each line, with buffering done at the controller level Passing characters on unmodified generally requires one interrupt per character The trend is to implement fancier line editing at a higher level (e.g., tcsh vs. csh, emacs vs. teco) Both raw and cooked tty input normally requires some _buffering_ This can be done either in hardware or software Could have tty buffering in one or more of: - hardware (device controller) - kernel space - user space Screen Driver -------------- Typical operations performed by the the screen driver for character oriented displays: - track cursor position - write char at cursor pos'n - write char at pos'n (x,y) - clear char, line, or screen, (The driver for bitmapped displays are often simple, as they turn over most of these chores to a higher level window manager) The character oriented display must - echo typed input - work with any low-level "line editing" commands, e.g., backspace, delete word, delete line, etc 3. Device-Independent Software =============================== The boundaries can get vague here and in practice several layers may be combined The device-independent layer - performs functions common to all devices and - provide a uniform interface to the user layer Examples of device independent functions: - mapping symbolic names (e.g, /dev/rfp021) to the right device driver - Providing protection (in Unix, file protection bits are used for all devices) - Provide buffering (e.g., between char at time user requests and block at a time devices) This layer is still typically implemented inside the kernel Unix sys calls (man 2) are in this layer 4. User Layer ============== Functions in this layer are implemented in user rather than kernel space Unix library routines (man (3)) are in this layer (e.g., printf, putchar, etc.) Other services implemented in the user layer: - spoolers (e.g., printer & batch spoolers) - mail and Usenet Disks (5.3) ============ ( covered earlier ) Clocks (5.4) ============= Hardware --------- Typically, system clock is counted down to some "tic" value, used for - time slice interrupts - tick counter available as a device register Most systems also have a battery-powered clock chip, similar to what's in a watch, that can supply date and time in a set of registers Software --------- Date, time, timing utilities Unix keeps time as seconds since Jan 1, 1970 Accounting and run-time profiling of code; may want to keep track of how much of each run burst is actually used Scheduling programs to run at specific times (e.g., unix chron and `at' utilities