I/O Management and Drivers in Operating Systems

1. CSI 400/500 Operating SystemsSpring 2009 Lecture #12 – I/O Management and Drivers Monday, March 16th, 2009

2. Why separate I/O Manager? • I/O access much slower than processor • Variety of I/O devices now • Variety of I/O methods • Local v Remote • Direct v Distributed

3. I/O Overlap • Term used to describe delay between start of I/O operation and end • Processing could progress, as faster • Old operating systems avoided by holding processing until I/O complete • Defeats purpose of separate Manager

4. Utilizing I/O Overlap • Requires two features: • Process designed to have other work to do while I/O executing • Means to poll I/O device to know completion • Requires constant communication between I/O Manager and Device Manager • Appropriate thought and planning in design of process assists this process

5. I/O Queuing • Many I/O Managers facilitate faster access by queuing write operations • Use of I/O buffers to allow faster reading • Reads large chunk, larger than initial request, so subsequent requests read from buffer, not device

6. I/O Strategies • Combinations of two considerations: • Transfer – data path between device and memory • Completion – means of knowing when I/O process is done • Transfer has two forms: • Direct I/O – transfer data to CPU register, then register writes to memory • DMA – direct connection between device and primary memory • Completion can use interrupts or polling

7. Common I/O Strategies • Direct polling • Direct interrupt-driven • DMA (or Automatic) interrupt-driven • Note DMA rarely uses polling. Since DMA bypasses CPU, other excludes process. Uses Operating System’s Interrupt Handler

8. Direct polling • Device driver copies data to register • Device driver continuously checks if I/O transfer is complete • Commonly done by checking if bus traffic still moving • When done, driver copies register contents to memory • Requires a dedicated register for I/O • Data references blocked until memory write

9. Interrupt-driven process • Same whether done by device driver in Direct I/O or I/O Manager in DMA system • I/O Interrupt triggered to process I/O request • Data marked as Blocked • Will suspend any process accessing it • I/O Interrupt triggers completion interrupt when done • Typically faster than polling

10. Linux Input Drivers • 2 forms: • Input Device Drivers : controls input device like normal device drivers • Input Event Drivers : controls actions from device as they interact with the system • Handles interaction with applications • Often connect with device drivers within the user space

11. Linux Input Event Drivers • Uses hardware-independent abstraction to allow device to interact with GUI application • Consists of three main parts: • Virtual driver : contains the crucial functions to process information • Evdev Interface : generic input device driver • Input Core : Repository of input data; where it gets dumped

12. Input Event Driver Process • Attach device’s read and/or write method • Define device attributes • Initialize driver • Register driver • Allocate data structure • Exit

13. Driver Registration • All Linux Input Event Drivers need to be registered as a device • Platform_device_register_simple( ) • Define input_handler structure in order to register • Good example of Linux Input Event Driver is for a Virtual Mouse, shown on p. 212-214

14. Linux Input Device Drivers • Defines hardware attributes • Allows open(), close(), start(), stop(), read() and write() methods • Collected in interface layer called SERIO • Register using serio_register_port() routine • Direct-connect devices (like keyboards and mice) need no SERIO layer