Chapter 13-3 I/O Systems

13.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Chapter 13: I/O Systems Chapter 13-1 and I/O Hardware Chapter 13-3 Application I/O Interface Kernel I/O Subsystem Transforming I/O Requests to Hardware Operations Performance

13.3 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Application I/O Interface

13.4 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Application I/O Interface There are so many devices and services that an operating system provides to the user (and itself). What we need is some kind of standard interface so that we are able to add new and different hardware with a minimum of hardware disruption. To do otherwise would require each and every new manufacturer of a new device to come up with their own interface, device drivers, etc…. The approach to accommodating a standard interface is as follows: Given general kinds of devices  standard device controller Interface  details of the required implementation will be found in the device drivers (these details are abstracted in the controllers for easy interface) Let’s look at a figure

13.5 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts A Kernel I/O Structure See the devices and their controllers Here’s the standard interface layer allowing easy addition of new devices. Note that this is all hardware

13.6 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Application I/O Interface Differences are found in the specific device drivers and are abstracted in device controller layer, as mentioned. So a new device can conceivably hook to an appropriate part – interface - of this controller layer. Further, by abstracting the device drivers into the device controller layer, we only need a limited number of controllers – far fewer than a much larger number of specific device drivers. Ideally, new hardware devices themselves need only be compatible with an existing host controller interface (Alternatively a manufacturer may need to write specific device drivers to interface the new hardware to the popular operating systems The device-driver layer also hides differences of very specific device drivers from the I/O subsystem of the kernel. So what we are doing is to insulate the this I/O subsystem itself from ever-arriving new devices and their technologies (and their specific device drivers). In action, I/O system calls are used to invoke the required I/O services (reads, writes, list, etc. - all these services / behaviors and these encapsulate these in rather generic ‘classes’ of devices.

13.7 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts General Categories of I/O Devices Almost all the communications from these devices to the device controllers are handled via system calls (down in the I/O subsystem) that involving: Character-stream or block  Characters and blocks are transferred as units/ Sequential or random-access  Sequential (in order) random (via key) Sharable or dedicated  Sharable devices can be accessed concurrently by a number of processes; dedicated devices cannot. Speed of operation  Huge range of speeds read-write, read only, or write only  Clearly some devices are one or the other. While there are differences in access and while the system calls may cause different algorithms and support data structures to be developed in support of the system calls, the device categories themselves (hence, the abstractions) are reasonably standard. Let’s look at some of these categories in a little bit of detail – but not too much.

13.8 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Major Access Conventions Character and Block I/O are well known. Memory-mapped file access and network sockets will discussed ahead. (a couple of slides up.) Also, other devices (in addition to the standard I/O considerations) are commonly available via system calls too. Some of these include timers, interval timers, graphical display devices, and more. I strongly expect that you have used some of these in your programming. Interesting is the escape (or ‘back door’ – as your authors call it). Invoking this system call passes commands typically from some application (we’ve all used this one) to a device driver. Perhaps you’ve coded where you used this ‘call’ associated with the ‘Escape.’ In Unix, the system call is to ioctl()) This system call allows the application to access any functionality implemented via a device driver without the need to develop a new system call – although conceivably one could – but why?. Essentially, this allows us to program our own system call. This can be easily programmed from applications.

13.9 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Characteristics of I/O Devices This is just a general slide providing a view of characteristics of some I/O devices by category

13.10 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Block and Character Devices (system calls) Block devices using standard system calls: Commands include read, write, seek for random-access devices and others. Most application developers use a file system for these system calls. The file system causes the system calls to be invoked and thus handles all the low level details. Raw I/O or file-system access Here, applications can ‘roll their own’ so to speak.  Are typically provided a linear array of blocks on disk to manage and control.  No buffering, pre-fetching, locking; no file system..  Again, all is the responsibility of the application, and no file system is typically used, (If any features of the file system were to be used, they’d be superfluous.) Memory-mapped file access possible Here, the memory-mapped file access can be imposed on top of block device drivers. System calls here map a file into primary memory and return a virtual memory address containing a copy of the file. (Variations on implementing this – buffering, etc. Actual data transfers are only performed when a reference is made to an item that is not present in primary memory. (demand-paged virtual memory). Memory-mapped file access is, in practice, as simple as accessing primary memory because of our accustomed paging mechanisms. Character devices include keyboards, mice, serial port input/outputs Commands include get, put and other rather simple system calls. Libraries of services are layered on top of these to allow line editing, buffering, and some editing services such as backing up within a keyboard buffer, and similar facilities.

13.11 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Network Devices (system calls) There are many network devices and their interfaces vary significantly from those accustomed block and character types. An Internet socket (or commonly, a network socket or socket), is an end- point of a bidirectional process-to-process communication flow across an IP-based network, such as the Internet. Sockets are mapped to an application process or thread and are used as the mechanism supporting communications between communicating processes.. A socket is really just an interface between an application process or thread and the TCP/IP protocol stack provided by the operating system. An Internet socket itself is identified by the operating system as a unique combination of the following: Protocol (TCP, UDP or raw IP) for communications / handshaking… Local IP address Local port number Remote IP address (Only for established TCP sockets) Remote port number (Only for established TCP sockets)

13.12 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts More on Network Devices Using our accustomed system calls in the interface allows us to create a socket, to connect a local socket to a remote address, listen for any remote application to plug into the local socket, and to send/receive packets over such a connection. The socket interface software typically provides a select() that really manages a set of sockets, and this function returns information about which sockets have a packet waiting to be received and which sockets have room to accept a packet to be sent. The select() function eliminates our need to poll and incur busy waiting which would normally be required for network I/O. There are a lot of other approaches to inter-process communication and network communications that are beyond the scope of this course, but certainly covered in a typical networking course.

13.13 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Clocks and Timers (system calls) Provide current time (stored in the machine – retrieval in various formats), elapsed time (we often use this to check performance), Timer – schedule some event to occur at a specific clock time – like ‘run this’ at 3am. Programmable interval timer used for timings, periodic interrupts This is the mechanism used to control time sharing. The scheduler uses this timer to control time slicing. This timer also sometimes used to by the disk I/O subsystem to flush dirty disk cache buffers periodically. This timer is also used in the network I/O subsystem to cancel very slow operations due to network congestion. Of course, as an application developer, a user can invoke the services of this programmable interval timer. Kernel software needs it own routines serviced by the timer in order to provide equitable services to user processes. The kernel maintains a prioritized list of needs ordered on ‘earliest-time-first-order.’ On most computers, an interval rate is generated by a hardware clock, which may be built from a high frequency counter. Naturally, there is some degree of coarse resolution of the timer due to the incredible internal computing speeds of a CPU commonly available to us today.. There are many other extensions / uses of the system clock too.

13.14 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Blocking and Nonblocking I/O (system calls) Applications have a choice: (sometimes!) Blocking - process suspended until I/O completed Easy to use and understand Process (or thread) is moved to a wait queue pending completion of the system call. Upon completion of the system call, this process receives values returned by the system call itself and will normally be moved back (rescheduled) by I/O subsystem to a ready queue to be rescheduled for execution. For an application interface, this is the norm. Insufficient for some needs Nonblocking - I/O call returns as much as available Non-blocking calls do not halt the execution of an application for an extended time. User interface, data copying (buffered I/O) and other similar activities. Returns quickly with count of bytes read or written

13.15 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Blocking and Non-Blocking I/O System Calls. Asynchronous - process runs while I/O executes These calls return right away without waiting for the I/O to complete. I/O subsystem signals process when I/O completed thru setting some variable in the address space of the application. Differences between non-blocking system calls and asynchronous system calls are significant: Non-blocking read(), for example, returns immediately with whatever data is available (some, none, or all); An asynchronous read() requests a transfer to take place and the application will be informed when all of the transfer has taken place. The asynchronous approach is rather difficult to use.

13.16 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Kernel I/O Subsystem We were cut short today due to Wimba problems. I covered more slides than this, but we are uncertain as to how many. So ‘next’ lecture will back up a bit and start here.

End of Chapter 13-3