Rather early on a document was distributed which included the following statement of the purpose of the architecture project: I. Overview The VMS SCSI implementation has a fairly long history, having originated with what is reported to have been a hasty implementation for a couple low end VAX processors and having been morphed into its current form from those beginnings, with some considerable rewrites of major sections and redesign of some areas. Because of this history, and various personnel turnover, there currently exists no overall written VMS SCSI architecture, but rather one must resort to examination of source code to find what the system does and how it does it. The system has an implementation but no formal design, and as a result the design one infers from it is not uniform. Further, performance (speed) of the current SCSI code base is regarded as lower than it might be. Finally, because of the lack of an overall architecture for SCSI there is a suspicion by management that the current code base may prove difficult over the long term to maintain and to migrate to newer systems. As a result, management has commissioned an effort to produce a modified SCSI architecture. This architecture must be specified under the constraint that it must be migratable to new adaptors (and provide a reasonable base for SCSI-3, which is not complete at this time), but also that it must be able to be realized in code by 3Q CY96. The latter point precludes a complete ground-up rework of the SCSI system; time and manpower are not available for such. The ability to reuse significant parts of the existing code base to support old adaptors and devices will therefore as a practical matter be required. It is desirable that some generalizations to the current device models be considered. Devices not well modelled by the current system are WORM, opticals, jukeboxes of various sorts, and CDs which contain multiple tracks (multisession CDs). II. General Wish List Items. Features desired of the new system: 1. Documentation of design principles and reasons for them 2. Clarity both of code and documents 3. Performance improvements. This includes generic design and fixes for specific issues like io$_writecheck and io$_dse and for supporting write cache enable. 4. Support for fast path, shadowing, SCSI clusters, failover, and bad block handling (where these require support from the driver components). 5. Support for revised device naming system 6. Port driver flow control; particularly, support of the ability to find out from a port driver that it can handle only X commands at a time. Also suitable monitoring to allow tuning of all adjustable parameters which may be introduced. 7. Unified and clearly specified error logging functions and error monitoring. 8. Status available at class drivers so that they need not guess at underlying bus and device status. (This has been an issue for MKdriver.) There also needs to be a better way to make status available above class drivers. 9. Clear description of the port/class driver binding. Not only what the interface between these is, but how one discovers what class drivers need to be connected with what port drivers. (This is heavily connected with the revised driver naming system.) 10. Ability to support wide variety of devices (incl. 3rd party commodity...) 11. Support for other device types and extensibility for the future (see above.) These features have been mentioned as things wanted of a new SCSI design, not all of which exist in the current code base. It should be added that a redesign should attempt to fit together so that attributes of a design reenforce one another. This is a rule of thumb, but is important enough to mention. In thinking about a piece of altered code, it is good to search for something that fits with the rest of the system as conceived so the overall complexity grows more slowly than the system size. ------------------------------------------------------------------------- The following text gives a bit of the history of what the SCSI group has been doing in the SCSI architecture area. It was intended to fill the first couple steps in for a LOP type statement after some additions were made for it. (G. C. Everhart) (Abstract) This is the Project Plan for the development of (PROJECT_NAME). This capability is current planned as the basis for upgrades to the SCSI code base beginning in the GRYPHON release. This project plan is in:

STAR::DOCD$:[EVMS.PROJECT_DOCUMENTS]SCSIArchitecture.PS and .TXT (Review Team)

(Ken Munsell\Group Manager) (Richard Critz\Technical Leader) (Pat St. Laurent\Supervisor) (1995) (-4)

This Project Plan describes how to build, test, integrate, and deliver the Software Component (PROJECT_NAME) for OpenVMS AXP (and/or) OpenVMS VAX.

(Digital Equipment Corporation--Project Plan\Digital Confidential) (Project Description)

Describe the project, stating what it is, and why the work should be done. Identify any unusual or problematical areas. Specify whether the work is for both VAX and Alpha, or for only one platform. The SCSI architecture project is part of an effort to proactively maintain the SCSI code base by producing first an overall architecture (meta design) document (which is the subject of the architecture project) and subsequently reworking parts of the SCSI code base to conform to the documented design.

The problem, as has been determined by responsible technical people and confirmed by the SCSI group's own retrospective, is that the SCSI code has become difficult to maintain and understand. This has been attributed to the lack of any residual design, the absence from the scene of all the original designers of the ancestral code, and to the tendency the code shows to having grown by accretion as patches have been piled on patches to deal with one-up problems. At any rate, no functional specification, design, or other reliable document save the source code itself describes the existing SCSI code base, and there is no population of "code gurus" available to fill the gap with oral lore. That this tends to exacerbate the situation is obvious. It has been feared that leaving this situation unaltered would lead to a large amount of bug fixing activity and make adding new features, new device support, and performance improvement impossible.

Investigation has been conducted informally. Alternatives rejected early on included porting the DEC Unix CAM code base to VMS (believed to be too costly in terms of handling the different VMS synchronization requirements and technically risky) and continuing a maintenance mode (believed to lead to paralysis and high QAR/CLD costs as new devices appear in the field). It was also stated early on that resources did not and do not exist to rewrite the entire SCSI code base all at once. The alternative preferred was to develop a clean architecture from the start, writing down the rationale for decisions embedded there, and develop a plan for selective migration of parts of the system while continuing to use others with possibly some glue code to enable use of existing components with new ones.

The approach of simply cleaning up the existing implementation without considering other possibilities, it should be added, was also rejected early, since this would foreclose any possibility of major improvements which might result from encouraging "blue sky" thinking as input to the ultimate top level design. Rather, it was decided to attempt to elicit as many "blue sky" ideas as possible from the resident VMS SCSI experts in order to acquire a fund of such ideas some of which might be used in an improved top level ordering of the design. This was NOT intended to mean that a result of the group investigation might not be largely or even wholly identical to the VMS 6.2 SCSI design, but rather that it was necessary that group members examine alternatives, in a fairly unconstrained way, and write down what their conclusions were about what the best SCSI implementation they could think of would look like. The difference is that other possibilities WERE to be considered, and that choices, and reasons for choices, were to be written down.

A bit of history: In support of this, a document was prepared giving one such "brain dump" incorporating a problem statement, and this passed on to the entire SCSI group. The group was then encouraged to produce its own sets of plans for a top level SCSI system design, assuming in their case "a blank sheet of paper" in order to elicit the largest possible number of ideas about how the SCSI subsystem might be improved,

From this a summary design document was produced outlining at very high level a set of architectural rules of thumb. Several subordinate investigations were then parcelled out to the group to get detail to fill in, the object being to approach more closely a complete top level specification which would lead to component design LOP investigations. (In this case "component" means things like port or class drivers or common modules.) Plans have been beyond these investigations to merge them into the architecture document and add an I/O flow to the architecture document (tracing a single I/O through the proposed system), then again to parcel out the tasks of describing interfaces within the system in somewhat more detail. (What is beyond such high level descriptions is viewed as belonging properly in the realm of design rather than of architecture.)

The architecture project specifically has been directed to produce a clean SCSI architecture. A bias was stated to the responsible engineer that a clean migration path exist, though this was treated as a refutable presumption. A sufficiently promising new design might cause downstream plans for migration to be readdressed, though it was considered most likely that such a revolutionary design would not be forthcoming. (That the current code base on the whole has been functioning well argued that the result would be closer to a cleanup than a rebuild from scratch.) The plan for migration becomes important late in the architecture definition phase, since it influences many detail decisions which must be made.

The major uncertainty about the project stems from its level of abstraction. It involves creating a design FOR designs, at the very top level of abstraction, and hence is rather far removed from the usual and concrete problems one encounters in making actual devices work. While some aspects of the layering chosen are informed by the collective experience of the workers in how the existing code base is laid out, and while the result must conform to what the rest of VMS needs from disk, tape, etc. drivers, describing a top level design in the absence of many particulars runs the risk of losing touch with what is possible to real code and real devices. This risk has been mitigated by the tendencies of the SCSI experts to consider concrete examples, but cannot be fully retired until architecture-compliant code is built and tested, and the architecture revised to conform to any lessons learned. Therefore the architecture document is viewed not as a graven-in-stone monument, but as a mutable document which must be made to conform to the VMS understanding of the SCSI world over time.