TANNENBAUM: 5, BIC & SHAW, SILBERSCHATZ: 12 INPUT/OUTPUT DEVICE DRIVERS TASK Accept commands from higher-level processes of i/o system Interact with devices it controls to carry out the commands BY DEVICE TYPE Block-Oriented: read or write a block of data specified by its block number Stream-Oriented: get or put next character in stream Communications: send/receive a data packet to/from another machine specified by its network address DOWN, DOWN Driver translates commands to low-level operations issued by device controller Communication between driver and controller done by reading/writing controller registers Registers constitute the software/hardware interface DEVICE CONTROLLER INTERFACE 1.Controller detects new opcode 2.Sets busy register 3.Status register reports outcome of request 4.Driver may access data buffer MEMORY-MAPPED INTERFACES KEY IDEA: SPECIAL INSTRUCTIONS NOT NEEDED FOR I/O REQUESTS a)Non-Memory-Mapped b)Memory-Mapped Sample Instruction to store contents of a register to a memory location >store cpu_reg, k 0 store cpu_reg, n stores the contents of cpu_reg to register 0 of controller 0 Provides a uniform view of memory Simplifies i/o programming TWO FINAL ISSUES 1.How to detect the completion of controller operation? 2.What should move the data between the controller buffer and main memory 1A) DETECTING COMPLETION POLLING SCHEME 1.CPU writes operands for i/o op 2.cpu writes opcode. Causes execution and sets busy flag 3.Controller interacts with device 4.CPU polls the busy flag 5.CPU reads status register to detect problems 6.CPU copies contents of buffer to RAM POLLING PSEUDO-CODE Input: i = 0 do { write_reg(opcode,read); while(busy); ram_in[i] = data_buffer; ++i; compute; } while (data_available) Output is similar Key Point: CPU has two tasks that can be handed-off Checks for i/o completion Moves data between RAM and controller registers 1B) DETECTING COMPLETION INTERRUPT SCHEME 1.CPU writes operands 2.CPU writes opcode. Controller starts operation. Sets busy flag. Process blocks itself, giving up CPU. 3.Controller interacts with device. 4.Operation is complete. Controller issues an interrupt, suspending currently running process and resuming process waiting for i/o. 5.Resumed process examines status register. 6.Process copies buffer to main memory. INTERRUPT PSEUDO-CODE Input: i = 0 do { write_reg(opcode,read); block to wait for interrupt; ram_in[i] = data_buffer; ++i; compute; } while (data_available) Solves problem 1: No more busy-waiting But quite expensive: thousands of CPU instructions See Bic & Shaw, p. 383 for details GENERIC KEYBOARD DRIVER Keyboard_Input: i = 0 do { block to wait for interrupt; ram_in[i] = data_buffer; ++i; compute(ram_in[i]) } while (data_buffer != ENTER) 1.no write_reg because keyboard generates a character to its buffer when key is pressed 2.Drivers task: copy character to RAM 3.Loop until end of line character Raw Mode: All special characters (control, shift, F4... ) are copied to memory and interpreted by process Cooked (Canonical) Mode: Driver performs some line-editing. BACKSPACE erases last character entered from the buffer, but is not itself entered into the buffer. F4... 2) MOVING DATA FROM CONTROLLER BUFFER TO MAIN MEMORY Look Again at Step 6 in Slide 10 CPU moves data from controller buffer to main memory Could this be done more efficiently? DIRECT MEMORY ACCESS (DMA) 1.CPU writes operands including starting location in MM for transfer and number of bytes to be transferred 2.CPU stores opcode in controller register. Initiates controller which sets busy flag. Process blocks itself. 3.Controller interacts with device. 4.Controller copies data from buffer to MM (repeatedly as necessary) 5.Controller unsets busy flag and issues CPU interrupt. 6.CPU tests status registers DMA PSEUDO-CODE Input or Output: write_reg(mm_buf, m); write_reg(count, n); write_reg(opcode, read/write) block to wait for interrupt