An Operating Systems Vade Mecum

172 Transput Chapter 5within a reasonable time, on the assumption that the original message was damaged intransit. Of course, the acknowledgement may be the one that was lost or damaged, so therecipient must be prepared to deal with duplicate messages that the sender accidentallysent. Sequence numbers are used to distinguish messages so that the recipient can discardany message with a duplicate sequence number.5 THE PROCESS INTERFACEWe started this discussion by presenting the physical structure of devices and how theyconnect to the computer. Next, we dealt with the device interface and device driversinside the kernel. We now turn to the process interface to transput.In keeping with the Beautification Principle, the kernel may wish to introduce devicesat this level that don’t actually exist at a lower level. For example, the concept of a‘‘file,’’ which we discuss at length in Chapter 6, is purely the invention of the operatingsystem. Processes can pretend that each file is a separate device that can be read or written,but in fact those actions are translated by the operating system (typically by a filemanager in the kernel) into actions on the underlying devices, usually disks. Very fewprocesses, if any, deal directly with the disk device; in many operating systems, this deviceis completely hidden from processes.The concept of ‘‘file’’ can be used as a metaphor for all devices; Unix uses thiselegant idea to unify the process view of transput. Instead of presenting a different set ofservice calls for each kind of device, each device looks like a file and responds to servicecalls for files. One extra call is provided for special actions that can’t be fit into the metaphor,such as setting the density of a tape drive or setting the echoing characteristics of aterminal.Not only can devices be cast as special ‘‘device files,’’ but also this metaphor canbe extended to data structures that the kernel may want to make available to processes,such as the physical store of the computer (only available to privileged processes, ofcourse) or a ‘‘bit bucket’’ into which anything may be written but which always looksempty when read. In Chapter 9, we will see that inter-process communication can alsobe made to look like file access.The operating system designer has many alternatives in designing the data-transferpart of the service calls. We will discuss two issues that confront the designer: whethertransput should be synchronous and how locations are specified in main store. For thesake of discussion, we will start with six basic service calls that a process may makewhen dealing with a device. The details of the semantics of these calls will be discussedin the following sections.Open(device name, intent). This call tells the appropriate device driver that theprocess plans to use the given device. The intent indicates whether reading, writing,both, or just appending are desired. At this stage, deadlock-avoidance ordetection algorithms can be used, as discussed in Chapter 4, to make sure the processwill not be blocked forever waiting for the device. Similarly, the devicedriver can check to make sure the process has the necessary privileges to open the