SCSI-2 CAM Changes Proposal                                      X3T9.2/91-140
 
From: Jon Abilay, Henry Kannapell, and Matthew Nelson
   Apple Computer, Inc.
   Cupertino,  CA
 
To: John Lohmeyer X3T9.2 Committee Chairman
 
Date: August 28 1991
 
Subject: Proposed Additions and Modifications to CAM interface
 
Proposal 1 - Addition of Disconnect IO Function Code
We propose the addition of a new function code Disconnect IO Process, code 14h,
which allows CAM clients  to send a DISCONNECT message.   This request is
analogous to Terminate IO Process and Bus Device Reset requests, two other
request which allow CAM clients to send a message asynchronously.  The
following text should be added to the CAM specification:
 
8.3.5 Disconnect IO Process Request
This function requests that  an I/O operation which matches the path id /l
target/ lun ID reference and currently controls the SCSI bus be interrupted via
a DISCONNECT message.  It can be issued on any  IO request at any time.
 
TABLE 8-1x   DISCONNECT  I/O PROCESS REQUEST CCB
 
-------------------------------------------------
|  SIZE |  DIR    |                              |
-------------------------------------------------
|    4  |   O     |   Address of this CCB        |
|    2  |   O     |   CAM Control Block Length   |
|    1  |   O     |   Function Code              |
|    1  |   I     |   CAM Status                 |
|    1  |         |   reserved                   |
|    1  |   O     |   Path ID                    |
|    1  |   O     |   Target ID                  |
|    1  |   O     |   LUN                        |
|    4  |   O     |   CAM Flags (OSD)            |
-------------------------------------------------
 
This function shall return CAM Status of Request Completed Without Error.
The actual failure or success of the Disconnect Request is indicated only by
the disconnect operation taking place, and thus may not be visible to the
client of the CAM.
 
Proposal 2 - Addition of Version number as the first field in the CCB Header
We propose the addition of a new field located zero bytes offset  from the base
of the CCB named version number in the CCB header section.  The version number
uniquely identifies specific content and sequence of the CCB fields.  This new
field will allow CAM interface implementors to handle different CCB versions
during software development process.   Note that a higher version number does
not imply backwards compatibility for lower version numbers.  Conceivably, a
CAM implementation may be able to parse more than one version of CCB.
Implementations of CAM which do not support a particular version of CCB will
return a new CAM status of 19h, CCB Version Not Supported.
 
    TABLE 8-1  CAM CONTROL BLOCK HEADER
 
-------------------------------------------------
|  SIZE |  DIR    |                              |
-------------------------------------------------
|    4  |   O     |  Version number of this CCB  |
|    4  |   O     |  Address of this CCB         |
|    2  |   O     |  CAM Control Block Length    |
|    1  |   O     |  Function Code               |
|    1  |   I     |  CAM Status                  |
|    1  |         |  reserved                    |
|    1  |   O     |  Path ID                     |
|    1  |   O     |  Target ID                   |
|    1  |   O     |  LUN                         |
|    4  |   O     |  CAM Flags (OSD)             |
-------------------------------------------------
 
8.1x  CCB Version number
Indicates version number of the CCB.   Implementations of CAM which do not
support the specified version number of CCB will return a new CAM status of
19h, CCB Version Not Supported.
 
Proposal 3 - Structural change of existing fields in the CCB header.
 
a. Renaming of "PathID" .
We think that the field name "Path ID" is a misleading and inaccurate label
since it actually designates a port number or bus ID.  We propose renaming it
to either  "PortID" or "Bus ID".
 
b. Regrouping of fields if CCB header.
Some OS's may want to use handles or tokens to associate drivers to SCSI
connections and not necessarily via busID/targetID/LUN mechanism.  We propose
grouping the following byte-fields"reserved", "PathID", "TargetID" and "LUN "
into a 4-byte quantity named "Connection ID"  to satisfy a more general
approach.  In C coding terms, it can be expressed as:
 
 Typedef CONNECTION_ID union
{
   ulong   CONNECT_ID; // OSD Connection ID
   typedef PATH_ID struct
   {
   uchar   reserved;   // OSD reserved
   uchar   busID;  // SCSI port or Bus number
   uchar   targetID;   // Target ID
   uchar   LUN;// LUN ID
   } PATH_ID;
}  CONNECTION_ID;
 
    TABLE 8-1  CAM CONTROL BLOCK HEADER
 
-------------------------------------------------
|  SIZE |  DIR    |                              |
-------------------------------------------------
|    4  |   O     |  Version number of this CCB  |
|    4  |   O     |  Address of this CCB         |
|    2  |   O     |  CAM Control Block Length    |
|    1  |   O     |  Function Code               |
|    1  |   I     |  CAM Status                  |
|    4  |   O     |  Connection ID               |
|    4  |   O     |  CAM Flags (OSD)             |
-------------------------------------------------
 
9.1.14 Connection ID
This is an OS-dependent field which describes the SCSI connection to be made by
the IO process.  It may be used as a four-byte quantity referencing the
connection or as four one-byte fields composed of a reserved byte, bus ID,
target ID and LUN ID.