The following is my take on the problem to be solved.

The VMS SCSI code base has evolved largely without written documentation
and without written principles of organization. In addition, those
individuals who had been involved with it from the beginning have largely
left the group. In the meantime, many new SCSI devices have appeared and
new features and functions have been needed in the SCSI code base which
thus have been implemented with no access to a broad vision of what the
complete I/O path through the SCSI subsystem should be. This has led to
a "patch" style of maintenance in many cases, where unique functions
are added in localized modifications, sometimes inside conditional tests,
and in which schedule constraints have at times dictated leaving senseless
code in the code base because of the risk of removing it shortly before a
release.

As a result of this history, the code base has been getting progressively
less orderly and harder to maintain, and the training period needed for
anyone coming into the SCSI group is becoming uncomfortably long, and
must require weeks or more of code reading, since no better documentation
of the current architecture is available.

With the advent of still more SCSI devices and signs of a breakdown of
the original assumptions that SCSI need not address anything other than
some tapes and some disks, together with other uses of SCSI, the
difficulty of maintaining SCSI code and of getting new people "up to
speed" with the existing code has become an obstacle to adding desired
new functions to VMS.

For this reason, it has become critical that a SCSI metadesign and
finally a complete SCSI design be committed to documentation and
construction (incrementally, metadesign first, construction to its
standards second) . The design must be:
   * Clearly understandable at least in broad terms
   * Clean
   * Provided with ways to address device peculiarities and
	complexities imposed by devices customers have or want
   * Able to provide good I/O performance
   * Able to handle the address ranges of future SCSI standards
   * Able to support simpler problem diagnosing
   * Able to support "future" VMS needs (e.g. SCSI clustering,
	failover, wide devices
   * Able to account for its decisions.

The last point is important. A metadesign will consist of a set of
principles and/or rules of thumb which will bear on all aspects of
SCSI code, but the reasons why it specifies one choice and not another
will be vital in allowing it to be modified in the future to cover
situations not apparent today.

There are two possible approaches to writing a very high level metadesign
which may serve to organize cleanup or rewrite efforts:
   1. Describe the existing code base and suggest possible mods, or
   2. Describe what SCSI ought to look like, not limiting oneself
	to the existing code base.

So long as it is clearly understood that the existing design is a
candidate for what SCSI ought to look like, the latter approach seems
most inclusive of new ideas. Given that an incremental implementation
is a practical necessity the results probably will not differ much, but
approach 2 avoids the temptation to do fine detail examination of parts
of the current code base and miss its broader features.

A series of rules of thumb against which to gauge code implementations
requires such a view.

What should result in the end is a documented subsystem. The overall high
level features need to be laid out first because there must be principles
in place to allow us to resist temptations to do patch-style customizations
for unique features and to help lay out where major functions within
SCSI (error handling, parameter checking, function determination, etc.)
are to be located. This design document MUST BE MUTABLE, however, and
be kept up to date as elements of the system are designed. This also
means that the high level documenting stops as a single activity when
major features of interfaces are laid out. (This means input/output/function
for port/class interface, port common to adapter, and class common to class
specific interfaces at minimum, though in very general terms only so that
function names are chosen and coarse structures laid out, but not all
details get filled in.) Rework of drivers or the like will necessarily
refer to existing ones to ensure all functions are handled, but MUST be
accompanied by documentation, both to update the upper level document and
to describe what is written.