Device Management

1. Operating Systems: A Modern Perspective, Chapter 5

2. DeviceManagement 5 Operating Systems: A Modern Perspective, Chapter 5

3. Input/Output Devices Output Device Processor Input Device Operating Systems: A Modern Perspective, Chapter 5

4. I/O devices • Each I/O device consists of a device controller and the physical device itself. • Devices: - storage devices: for permanent storage (e.g. disk, tape) - communication devices: to transfer data from the computer to another machine (e.g. keyboard, a terminal display, or a serial port to a modem or a network). • Devices can be character-oriented (e.g. a terminal) or block-oriented (e.g. a disk) Operating Systems: A Modern Perspective, Chapter 5

5. I/O Devices (cont.) • Device controller: hardware that connects the device to the computer’s address and data bus: • continuously monitors and controls the operation of the device. • provides an interface to the computer: a set of components that the CPU can manipulate to perform I/O operations. Need to have a standard interface so that devices can be interchanged. Operating Systems: A Modern Perspective, Chapter 5

6. Application Program Device manager System Bus Device Controller Device I/O devices • Device Manager: consists of a collection of device drivers • hide the operation details of each device controller from application programmer. • provide a “common” interface to all sorts of devices. e.g. Open, close (to allocate/deallocate device), read/write, etc. Operating Systems: A Modern Perspective, Chapter 5

7. The Device Driver Interface … write(…); … Device Interface Terminal Driver Printer Driver Disk Driver Terminal Controller Printer Controller Disk Controller Operating Systems: A Modern Perspective, Chapter 5

8. Infrastructure and device drivers • Device Manager is composed of device manager infrastructure (device independent part) and a collection of device drivers (device dependent part) • Infrastructure: • exports the common device interface as system calls • Routes calls on the generic interface to specific device driver functions Operating Systems: A Modern Perspective, Chapter 5

9. Device Management Organization Application Process System Interface File Manager Device-Independent Device-Dependent Hardware Interface Command Status Data Device Controller Operating Systems: A Modern Perspective, Chapter 5

10. System Call Interface • Functions available to application programs • Abstract all devices (and files) to a few interfaces • Make interfaces as similar as possible • Block vs character • Sequential vs direct access • Device driver implements functions (one entry point per API function) Operating Systems: A Modern Perspective, Chapter 5

11. Example: BSD UNIX Driver open Prepare dev for operation close No longer using the device ioctl Character dev specific info read Character dev input op write Character dev output op strategy Block dev input/output ops select Character dev check for data stop Discontinue a stream output op Operating Systems: A Modern Perspective, Chapter 5

12. I/O Strategies • Direct I/O with polling • DMA I/O with polling • Direct I/O with interrupts • DMA I/O with interrupts Operating Systems: A Modern Perspective, Chapter 5

13. Performing a Write Operation Device driver: 1. While (device is not idle) keep checking; 2. Set command register to WRITE and set busy flag to 1. 3. Move address of source into address register of controller 4. Move data to be written into data registers of the controller. Device-Controller: 1.Store data from data registers into the device. 2. When operation is completed, clear busy flag and set done flag to 1. 5. Wait for busy flag to be cleared when busy flag becomes clear, clear done flag to 0. Operating Systems: A Modern Perspective, Chapter 5

14. Performing a Write Operation Device Driver: while (device.busy || device.done) <keep checking>; device.data[0] = <value to write>; device.address[0] = <address of source> device.command = WRITE ; this also sets busy flag while (device.busy) <keep checking>; device.done = 0; return to calling process; Operating Systems: A Modern Perspective, Chapter 5

15. Performing a Read Operation while (device.busy || device.done) <keep checking>; device.command = READ ; this also sets busy flag device.address[0] = <address of destination> while (device.busy) <keep checking>; Move value in device.data[0] to memory or CPU register; device.done = 0; • Note: • Polling is used to determine status of I/O device • while device operates, the CPU waits. When device is done, CPU continues with rest of program • => Direct I/O with polling Operating Systems: A Modern Perspective, Chapter 5

16. Polling I/O Read Operation read(device, …); 1 Data System Interface read function 5 write function 2 3 4 Hardware Interface Command Status Data Device Controller Operating Systems: A Modern Perspective, Chapter 5

17. Overlapping the Operation of a Device and the CPU . . . startRead(dev_I, “%d”, x); . . . While(stillReading()) ; y = f(x) . . . . . . read(dev_I, “%d”, x); y = f(x) . . . Data on device Variable x Register Device dev_I Memory CPU Operating Systems: A Modern Perspective, Chapter 5

18. Overlapping CPU-Controller Operations in a Process App I/O Ctlr t1 t2 t3 t4 t5 t6 t7 t8 t9 Operating Systems: A Modern Perspective, Chapter 5

19. Overlapping Processing and I/O App 1 App 2 I/O Ctlr t1 t2 t3 t4 Operating Systems: A Modern Perspective, Chapter 5

20. Interrupt Driven I/O • Instead of having the CPU continuously poll status register of I/O device(s), have I/O device notify CPU when it has completed an I/O operation. • CPU initiates an I/O operation as described before • as I/O device performs the operation, CPU is switched to another process (thru the process scheduler). • When the I/O device is done, it notifies the CPU by sending it an interrupt signal. • The CPU switches control to an interrupt handler to service the interrupt. • The interrupt handler completes I/O operation and returns control to interrupted process. Operating Systems: A Modern Perspective, Chapter 5

21. Interrupt Driven I/O • An InterruptRequestflag is incorporated in the CPU • Whenever an I/O device has completed its I/O operation, it sets the InterruptRequestflag to 1. • Conceptually, this can be done by connecting the doneflags of all I/O controllers to the InterruptRequest flag through an OR gate. • Control unit of the CPU must check the InterruptRequest flag before it starts each instruction. If flag is set, it jumps to an interrupt handler program. Operating Systems: A Modern Perspective, Chapter 5

22. Interrupt Driven I/O Operating Systems: A Modern Perspective, Chapter 5

23. Fetch-Execute Cycle with Interrupt PC = <Machine-Start-Address> ; IR = Memory[PC] ; haltFlag = CLEAR ; Decode(IR); while (haltFlag not SET) { Execute(IR); PC = PC + InstructionSize; if (InterruptRequest) { save current PC; // (e.g. in system stack) PC = AddressOfInterruptHandler; } IR = Memory[PC] ; Decode(IR); } Operating Systems: A Modern Perspective, Chapter 5

24. Interrupt Handler The Interrupt Handler is a program that is part of the device manager. Each time it is called it does the following: 1. Save the state of the interrupted process: save the contents of CPU registers (all registers) and load CPU registers with its own values: Context Switch 2. Determine which I/O device caused the interrupt 3. Branch to the device driver associated with that device. Operating Systems: A Modern Perspective, Chapter 5

25. Interrupt Handler Interrupt_Handler { clear InterruptRequest flag; saveProcessorState(); // Context Switch for (i=0; i < Number_of_devices; i++)//poll if (device[i].done == 1) goto device_driver(i); } Operating Systems: A Modern Perspective, Chapter 5

26. Device Driver • The device driver is a program that is part of the device manager. When called, it does the following: • determine the cause of the interrupt • complete the I/O operation • clear the done flag of the device controller status register • restore the state of the interrupted process context switch • return control to interrupted process Operating Systems: A Modern Perspective, Chapter 5

27. Interrupt Vector How can we avoid having the interrupt handler poll all the devices to determine which one caused the interrupt? • Replace the InterruptRequest flag with an interrupt vector, ie. a collection of flags, one flag for each device. • Replace the OR gate with a vector of interrupt request lines one for each device. • An Interrupt Vector Table: a table of pointers to device drivers : entry i of the table stores the address of device driver i. • The interrupt vector table is generally stored at a fixed location in memory (e.g. first 100 locations). Operating Systems: A Modern Perspective, Chapter 5

28. Race Condition What if a second interrupt occurs while the first is being processed? two possibilities: 1. Disable all other interrupts while an interrupt is being processed • use an InterruptEnabled (IE) flag in CPU • provide instructions to set and clear the (IE) flag • Control unit must check the (IE) flag before processing any interrupt. if (InterruptRequest & InterruptEnabled ) { disableInterrupts(); save current PC and other CPU regs; PC = address of interrupt handler; } Operating Systems: A Modern Perspective, Chapter 5

29. Race Condition 2. Enable other interrupts while an interrupt is being processed • Must use system stack to save PC and state of the interrupted process. • Must use a priority scheme. • Part of the interrupt handler routine should not be interrupted. • Most CPUs have two types of interrupts: • maskable interrupts: can be interrupted • un-maskable interrupts: can not be interrupted Operating Systems: A Modern Perspective, Chapter 5

30. Performing a Read Operation Read(device_i, "%d", x) • CPU is executing some process (say process A) • Process A makes a request for a read operation to device i. This is done thru a system call to the OS • The device manager of the OS check validity of system call and if valid, invokes the device driver of device i. • The device driver queries the control status register (CSR) of device i to determine whether the device is idle. If the device is busy, the driver waits for it to become idle. Device driver may also have a queue of waiting I/O requests. Operating Systems: A Modern Perspective, Chapter 5

31. Performing a Read Operation (cont.) • The driver stores a READ command into the controller’s Command register ==> device Busy bit set to 1. • The CPU is switched to another process B while the I/O operation is being processed (device driver invokes CPU scheduler) • Eventually the device completes the READ operation and raises an interrupt to the CPU • The CPU is switched from process B to the interrupt handler. Operating Systems: A Modern Perspective, Chapter 5

32. Performing a Read Operation (cont.) • The interrupt handler determines which device caused the interrupt and calls the device driver of device_i. • The device driver determines what needs to be done and copies the contents of the controller’s data register(s) into the process space of process A (how does the device driver know which process?) • when the read operation is done, the device driver clears the done flag of the device controller and returns control to the interrupted process (i.e. process B) Operating Systems: A Modern Perspective, Chapter 5

33. Device Status Table • While an I/O operation is being done, the CPU may be switched to some other process (other than the one that requested the I/O operation) • At any point of time, there may be several I/O requests pending by various processes • When a device driver is called to finish an I/O operation, how does it know to which process the I/O operation belongs? • Device status table: a table containing information about each I/O device. Operating Systems: A Modern Perspective, Chapter 5

34. Device Status Table (cont.) • Contains an entry for each I/O device. • Each entry contains such information as: • device type, address, state (idle, busy, not functioning, etc.) • if device is busy: • the type of operation being performed by that device • the process ID of the process that issued the operation • for some devices: a queue of waiting requests for that device Operating Systems: A Modern Perspective, Chapter 5

35. Performing Read Operation • CPU is executing some process (say process A) • Process A makes a request for an read operation to device i. This is done thru a system call to the OS • The device manager of the OS, invokes the device driver of device i. • The device driver queries the CSR of device i to determine whether device i is idle. If the device is busy, the driver waits for it to become idle (or queues process if there is a queue). Else if the device is idle: • If the device is idle: The driver stores a read command into the controller’s Command register ==> device Busy bit set to 1. Operating Systems: A Modern Perspective, Chapter 5

36. Performing Read Operation (cont.) • The driver saves information regarding the I/O operation in the device status table. • The status of process A is changed from running to blocked • The device driver invokes the CPU scheduler, which switches the CPU to another process B • Eventually the device completes the operation and interrupts the CPU • The CPU is switched to the interrupt handler • Interrupt handler determine which device caused the interrupt and calls the device driver of device i. • The device driver retrieves information about the I/O operation on device i from the device status table ==> process A issued I/O operation Operating Systems: A Modern Perspective, Chapter 5

37. Performing Read Operation (cont.) • The device driver copies the contents of the controller’s data register(s) into the process space of process A. • Process A status should be changed from blocked to ready. • If there is a queue of requests for device_I, dispatch next request. • the device driver returns control to the interrupted process (i.e. process B). Operating Systems: A Modern Perspective, Chapter 5

38. Interrupt-driven I/O Operation read(device, …); 9 1 8b Data System Interface Device Status Table 4 7 Device Handler read driver 2 write driver 6 3 8a Interrupt Handler Hardware Interface 5 Command Status Data Device Controller Operating Systems: A Modern Perspective, Chapter 5

39. Device Independent Function Call Trap Table funci(…) dev_func_i(devID, …) { // Processing common to all devices … switch(devID) { case dev0: dev0_func_i(…); break; case dev1: dev1_func_i(…); break; … case devM: devM_func_i(…); break; }; // Processing common to all devices … } Operating Systems: A Modern Perspective, Chapter 5

40. Driver-Kernel Interface • Drivers are distinct from main part of kernel • Kernel makes calls on specific functions, drivers implement them • Drivers use kernel functions for: • Device allocation • Resource (e.g., memory) allocation • Scheduling • etc. (varies from OS to OS) Operating Systems: A Modern Perspective, Chapter 5

41. Reconfigurable Device Drivers System call interface open(){…} read(){…} Entry Points for Device j etc. Other Kernel services Driver for Device j Operating Systems: A Modern Perspective, Chapter 5

42. Handling Interrupts Device driver J Device interrupt handler J Device status table int read(…) { // Prepare for I/O save_state(J); out dev# // Done (no return) } void dev_handler(…) { get_state(J); //Cleanup after op signal(dev[j]); return_from_sys_call(); } J Interrupt Handler Device Controller Operating Systems: A Modern Perspective, Chapter 5

43. Handling Interrupts(2) Device driver J Device interrupt handler J int read(…) { … out dev# // Return after interrupt wait(dev[J}); return_from_sys_call(); } void dev_handler(…) { //Cleanup after op signal(dev[j]); } Interrupt Handler Device Controller Operating Systems: A Modern Perspective, Chapter 5

44. The Pure Cycle Water Company Customer Office Water Company Returning the Empties Water Producer Water Consumers Delivering Water Operating Systems: A Modern Perspective, Chapter 5

45. Hardware Buffering Process Process Process Controller Controller Controller Data A B A B Device Device Device Process reads bi-1 Controller reads bi Process reads bi Controller reads bi+1 Unbuffered Operating Systems: A Modern Perspective, Chapter 5

46. Double Buffering in the Driver Process Process A B A B Driver Controller Controller A B A B Hardware Device Device Operating Systems: A Modern Perspective, Chapter 5

47. Circular Buffering To data consumer Buffer i Buffer j From data producer Operating Systems: A Modern Perspective, Chapter 5

48. I/O Buffering A buffer is a memory area used to store data while it is being transferred between two devices or between a device and an application. • Used to reduce the effects of speed mismatch between I/O device and CPU or among I/O devices. • Generally used to allow more overlap between producer and consumer ==> more overlap between the CPU and I/O devices. Operating Systems: A Modern Perspective, Chapter 5

49. Compute vs I/O Bound Compute-bound Time I/O-bound Operating Systems: A Modern Perspective, Chapter 5

50. A Generic Communications Device Bus Generic Controller Communications Controller Local Device Cabling connecting the controller to the device Device • Printer • Modem • Network Operating Systems: A Modern Perspective, Chapter 5