Operating Systems Lecture Notes: Input/Output and I/O Devices, Study notes of Computer Science

Download Operating Systems Lecture Notes: Input/Output and I/O Devices and more Study notes Computer Science in PDF only on Docsity! Operating Systems CMPSC 473 Input/Output April 22, 2008 - Lecture 22 Instructor: Trent Jaeger e Last class: — File System Interface ° Today: —1/O af Talk to Devices • Communication – Send instructions to the devices – Get the results • I/O Ports – Dedicated I/O registers for communicating status and requests • Memory-mapped I/O – Map the registers into main memory – Communicate requests through memory • Memory-mapped data “registers” can be larger – Think graphics device Memory-mapped I/O • Can read and write device registers just like normal memory. • However, user programs are NOT typically allowed to do these reads/writes. • The OS has to manage/control these devices. • The addresses to these devices may not need to go through address translation since – OS is the one accessing them and protection does not need to be enforced, and – there is no swapping/paging for these addresses. Consider a disk device … Main Memory Memory Bus (e.g. PC133) I/O Bus (e.g. PCI) 0x00…0 0x0ff..f 0x100…0 0x1ff….f Controller RAM DMA engine to offload work of copying Main Memory Memory Bus (e.g. PC133) I/O Bus (e.g. PCI) 0x00…0 0x0ff..f 0x100…0 0x1ff….f Controller RAM DMA Store [Command_Reg], READ_COMMAND Store [Track_Reg], Track # Store [Sector_Reg], Sector # Store [Memory_Address_Reg], Address /* Device starts operation */ P(disk_request); /* Operation complete and data is now in required memory locations*/ ISR() { V(disk_request); } Called when DMA raises interrupt after Completion of transfer Assuming an integrated DMA and disk ctrller. Issues to consider • What is purpose of RAM on card? – To address the speed mismatch between the bit stream coming from disk and the transfer to main memory. • When we program the DMA engine with address of transfer (Store [Memory_Address_Reg], Address), is Address virtual or physical? – It has to be a physical address, since the addresses generated by the DMA do NOT go through the MMU (address translation). – But since it is the OS programming the DMA, this is available and it is NOT a problem. – You do NOT want to give this option to user programs. – Also, the address needs to be “pinned” (cannot be evicted) in memory. Characteristics of Devices aspect variation example Matetrancioninoda character terminal block disk sequential modem access method ana CD-ROM synchronous tape Dec asynchronous keyboard sharin dedicated tape 9 sharable keyboard device speed latency seek time transfer rate delay between operations read only CD-ROM 1/0 direction write only graphics controller read—write disk I/O Software • A layered approach: – Lowest layer (device dependent): Device drivers – Middle layer: Device independent OS software – High level: User-level software/libraries • The first 2 are part of the kernel. Device Drivers • Accept abstract requests from device-independent OS software, and service those requests. • There is a device driver for each “device” • However, the interface to all device drivers is the same. – Open(), close(), read(), write(), interrupt(), ioctl(), … Putting things together (UNIX) • User calls open(“/dev/tty0”,”w”) which is a system call. • OS traverses file system to find the i-node of tty0. • This should contain the (major #, minor #). • Check permissions to make sure it is allowed. • An entry is created in OFDT, and a handle is returned to the user. • When user calls write(fd, ….) subsequently, index into OFDT, get major/minor #s. I/O and Kernel Objects system-wide open-file table - active-inode file-system record table inode pointer be pointer to read and write functions pointer to select function Dl 1 pointer to ioctl function file descriptor» open-file table : : pointer to close function . network- information table 4 networking (socket) record user-process memory pointer to network info b> pointer to read and write functions pointer to select function pointer to ioctl function pointer to close function kernel memory Getting to the driver routine Open_fp; Close_fp; Read_fp; Write_fp; …. Open_fp; Close_fp; Read_fp; Write_fp; …. Open_fp; Close_fp; Read_fp; Write_fp; …. Major # Open() {…} Close() {…} Read() {…} Write() {…} …. Open() {…} Close() {…} Read() {…} Write() {…} …. In Memory Data Struct Driver codes supplied by h/w vendors Linked (needs kernel reboot for Installation) or dynamically loaded into Kernel. • This is all for the user referring to an I/O device (/dev/*). • Note: It is not very different when the user references a normal file. In that case, we have already seen how the file system generates a request in the form of a logical block id, which is then sent to the driver where the specified file system resides (disk/CD/…) Life Cycle of an I/O Request request /O system call can already satisfy request? send request to device driver, block process if appropriate | process request, issue commands to controller, configure controller to block until interrupted device-controller commands monitor device, interrupt when I/O completed user process kernel VO subsystem kemel VO subsystem device driver interrupt handler device controller VO completed, input data available, or output completed return from system call transfer data (if appropriate) to process, return completion or error code determine which VO completed, indicate state change to /O subsystem receive interrupt, store data in device-driver buffer if input, signal to unblock device driver t interrupt VO completed, generate interrupt Summary • Input/Output – The OS Manages Device Usage – Communication – I/O Subsystem