ITFT_Device management in Operating System
6 likes3,336 views
This document discusses different approaches to device management in computer systems, including direct I/O, interrupt-driven I/O, memory mapped I/O, and direct memory access (DMA). It describes how each approach handles coordination between software and hardware to complete I/O operations and optimize CPU usage. The key aspects covered are device drivers, buffering techniques, and the design of interfaces between applications, drivers, and device controllers.
ITFT_Device management in Operating System
- 2. Content • Device management approaches • I/O system organization • Direct I/O and Memory Mapped I/O • Direct I/O with polling • Interrupt driven direct I/O • Direct memory access • Buffering • Device drivers
- 3. Device Management Approaches (1) • Direct I/O – CPU software explicitly transfer data to and from the controller’s data registers • Direct I/O with polling – the device management software polls the device controller status register to detect completion of the operation; device management is implemented wholly in the device driver, if interrupts are not used • Interrupt driven direct I/O – interrupts simplify the software’s responsibility for detecting operation completion; device management is implemented through the interaction of a device driver and interrupt routine
- 4. Device Management Approaches (2) • Memory mapped I/O – device addressing simplifies the interface (device seen as a range of memory locations); • Memory mapped I/O with polling – the device management software polls the device controller status register to detect completion of the operation; device management is implemented wholly in the device driver. • Interrupt driven I/O – interrupts simplify the software’s responsibility for detecting operation completion; device management is implemented through the interaction of a device driver and interrupt routine • Direct memory access – involves designing of hardware to avoid the CPU perform the transfer of information between the device (controller’s data registers) and the memory
- 5. I/O system organization • An application process uses a device by issuing commands and exchanging data with the device management (device driver). • Device driver responsibilities: • Implement communication APIs that abstract the functionality of the device • Provide device dependent operations to implement functions defined by the API • API should be similar across different device drivers, reducing the amount of info an application programmer needs to know to use the device • Since each device controller is specific to a particular device, the device driver implementation will be device specific, to • Provide correct commands to the controller • Interpret the controller status register (CSR) correctly • Transfer data to and from device controller data registers as required for correct device operation Application Process File Manager Device Driver Device controller command status data Hardware interface API
- 6. I/O with polling • Each I/O operation requires that the software and hardware coordinate their operations to accomplish desired effect • In direct I/O pooling this coordination is done in the device driver; • While managing the I/O, the device manager will poll the busy/done flags to detect the operation’s completion; thus, the CPU starts the device, then polls the CSR to determine when the operation has completed
- 7. I/O with polling - read 1. Application process requests a read operation 2. The device driver queries the CSR to determine whether de device is idle; if device is busy, the driver waits for it to become idle 3. The driver stores an input command into the controller’s command register, thus starting the device 4. The driver repeatedly reads the content of CSR to detect the completion of the read operation 5. The driver copies the content of the controller's data register(s) into the main memory user’s process’s space. read (device, …); Device controller command status data Hardware interface System Interface data read function write function 1 2 3 4 Datatransfer 5
- 8. I/O with polling - write 1. The application process requests a write operation 2. The device driver queries the CSR to determine if the device is idle; if busy, it will wait to become idle 3. The device driver copies data from user space memory to the controller’s data register(s) 4. The driver stores an output command into the command register, thus starting the device 5. The driver repeatedly reads the CSR to determine when the device completed its operation write (device, …); Device controller command status data Hardware interface System Interface data read function write function 1 2 4 5 Datatransfer 3
- 9. Interrupt driven I/O • In a multiprogramming system the wasted CPU time (in polled I/O) could be used by another process; because the CPU is used by other processes in addition to the one waiting for the I/O operation completion, in multiprogramming system may result a sporadic detection of I/O completion; this may be remedied by use of interrupts • The reason for incorporating the interrupts into a computer hardware is to eliminate the need for a device driver to constantly poll the CSR • Instead polling, the device controller “automatically” notifies the device driver when the operation has completed.
- 10. Overlapping CPU execution with device operation • The software interface to an I/O device usually enables the operating system to execute alternative processes when any specific process is waiting for I/O to complete, while preserving serial execution semantics for an individual process • That means that whenever the programmers will use read statement in a program, they will know that the next instruction will not execute until the read instruction has completed. • Consider the following code: … read (device, “%d”, x); y=f(x); ….
- 11. Direct memory access • Traditional I/O • Polling approach: • CPU transfer data between the controller data registers and the primary memory • Output operations - device driver copies data from the application process data area to the controller; vice versa for input operations • Interrupt driven I/O approach - the interrupt handler is responsible for the transfer task Primary memory CPU Controller Device
- 12. Direct memory access• DMA controllers are able to read and write information directly from /to primary memory, with no software intervention • The I/O operation has to be initiated by the driver • DMA hardware enables the data transfer to be accomplished without using the CPU at all • The DMA controller must include an address register (and address generation hardware) loaded by the driver with a pointer to the relevant memory block; this pointer is used by the DMA hardware to locate the target block in primary memory Primary memory CPU Controller Device
- 13. Design Objectives • Efficiency • Most I/O devices are extremely slow compared with the processor and the main memory • Buffering is one way to deal with this issue • Generality • It is desirable to handle all devices in a uniform and consistent manner • Applies for both • The way the user processes see the devices • The way the operating system manages the I/O devices and operations
- 14. Buffering • Buffering is the technique by which the device manager can keep slower I/O devices busy during times when a process is not requiring I/O operations. • Input buffering is the technique of having the input device read information into the primary memory before the process requests it. • Output buffering is the technique of saving information in memory and then writing it to the device while the process continues execution
- 15. Device manager design • Designing the device manager involves to invoke controller specific I/O operations while satisfying: • Create an API that implements the I/O functions available to the device, still compliant with interfaces implemented by other drivers; this is called device driver interface • Achieve correct coordination among the application processes, drivers and device controllers • Optimize the overall machine performance with correct driver strategies
- 16. Device driver interface • Each operating system defines an architecture for its device management system • The designs are different from operating system to operating system; there is no universal organization • Each operating system has two major interfaces to the device manager: • The driver API • The interface between a driver and the operating system kernel