ECS SYSTEM I-O FACILITIES

The major consideration in the design of the I-O system was having the code in the heart of the system as simple as possible. There were a number of reasons for this, but the paramount one was to allow as much of the system as possible to continue running, even in the face of an error in some infrequently used or special purpose part. For example, we wanted to be able to add code to drive special purpose I-O devices without a long check out period. If most of the code for the device had to be within the system, then a large effort would be required by system programmers, whereas if most of the code could be part of a user's process, then the system programmers could be responsible for only a small interface program in the system. Another consideration was experience derived from the SCOPE operating system which indicated that PPUs were very feeble machines. The SCOPE operating system depended on having large amounts of special purpose code in the PPUs, and significant problems developed trying to fit the code into the memories of the PPU's. Hence we felt that the more complicated device code should be in central. The general character of the I-O system was controlled by earlier decisions, and the hardware. There had to be some sort of device drivers in the PPUs. These would transfer data to and from buffers in central memory. As necessary they would signal special code in the ECS system which would transfer data to and from buffers in ECS. These ECS buffers would exist in ECS files, accessable to programs in user processes. Finally, as necessary, this special code would send and receive signals to and from user processes via event channels. Under the SCOPE operating system, PPU's were assigned to individual user programs for an I-O task. Each time such an assignment was done, the appropriate program had to be loaded into the PPU from some storage medium, usually the disk. This system had a number of drawbacks, the worst being the time required to load the program into the PPU. As one watched the system run, the same PPU program could be seen to move from PPU to PPU. It seemed that much more service could have been given if the program remained in one PPU and serviced several users. However, as the system designers had chosen to put a large amount of code in the PPU's, there was far more code than could fit in the 10 PPU's available. Thus they were essentially forced to swap programs into the PPUs. Aside from the overhead of swapping the PPU code, there was a second reason for avoiding the style used in the SCOPE system. We expected to have a large number of active processes, all frequently doing I-O. In the SCOPE system there were only 7 Control Points (or processes). Thus 10 PPU's could service these 7 processes moderately well, but would have trouble with more processes. We decided that the code in the PPUs should be simple, so that it could be resident at all times. As a hedge we held open the possibility of having one or two PPUs hold transient code, but this never proved necessary. Since the code in the PPUs had to be simple, and since we wanted to make all the potential uses of a particular device available to users, the interface between central and the PPUs had to be a logically complete description of the device. We did not want to convert the device to some virtual device, for example we did not want to implement the idea of files on magnetic tape within the PPU. Attempts to do this sort of thing in the SCOPE system had led to large amounts of code to implement the logical constructs of files, and left some of the features of tapes unavailable. For example, under the SCOPE system, it would be impossible for a central program to write ``in-place'' on a tape, whereas by direct control of the tape drive it is possible. This same argument can be used to show that the same sort of interface must be preserved between the central code and the user processes. We wanted to keep the amount of code within the system at a minimum, and attempts to implement the idea of files at that level could lead to the same problems. Thus the user process was to be presented with an interface that presented the full logical facilities of the device. In fact these ideas had to be modified in the face of timing constraints. It would be impossible, for example, to allow a user process to decide exactly what to write on the disk at each sector position, as that sector position came by. The reaction time of a process would be too large. Consequently, some logically equivalent interface would have to be found, if possible. The following are short descriptions of how we handled some I-O devices.