An Operating Systems Vade Mecum

Perspective 181to that terminal. If all terminals are very active, each one gets at least the 20 privatebuffers and can continue to function, although some will have the increased benefit of theextra buffers.We still have a problem. Suppose that all the public buffers are in use by terminal1. Terminal 2 only has its 20 private buffers. If the user on terminal 2 has typed ahead,all the private buffers may be filled with new input that the process has not yet read. Theprocess may be running a program that wants to print an answer to the previous queryand then accept a new query. When it tries to print the answer, it blocks because thereare no available buffers. It will never awaken (at least not until some public buffers arefreed) because the private buffers will not be freed until the process reads them, and itcan’t read them because it is blocked. We see that it is necessary to preallocate at leastone buffer for the process to produce into. Similarly, it is necessary to keep at least onebuffer for the user to produce into; otherwise the user may not be able to type the ‘‘halt’’character at a program that insists on printing at full speed to the terminal.Here is the moral: It is necessary to preallocate at least one buffer for every producer.All the rest may be allocated by need. It is typical to preallocate at least 80buffers to input from every terminal so that the user can always type ahead at least onecomplete line.6 PERSPECTIVETo live up to the Beautification Principle, the operating-system designer and implementormust deal with the most excruciating details of hardware and must turn a bewilderingtangle of complexity into a straightforward, simple, and regular view that a process candeal with. In carrying out this responsibility, the kernel must satisfy both masters.Luckily, most devices can be thought of as engines that consume and/or producedata and accept other specialized requests. This abstract view of devices can be embodiedin device drivers, which hide the idiosyncrasies of particular devices behind a maskof uniformity. Device drivers are controlled partly by interrupts and partly by requestsfrom the rest of the kernel. The rest of the kernel, including such parts as the swappingmanager, make use of these drivers whenever they must deal with devices. The drivershave responsibility for three areas.Efficiency: We saw how the disk driver could employ disk-head scheduling toimprove performance. Similarly, data compression may be used to reduce theamount of data that must be stored. Data compression may be applied at higherlevels, outside the kernel.Reliability: Drivers for unreliable communication lines may employ error detection,positive acknowledgement, retransmission on timeout, and sequence numbers.The responsibility for reliability is ultimately in the hands of the applications program,but the responsibility for the reliable transmission of individual messages,which is necessary for efficiency of higher-level protocols, lies in the hands of theoperating system.