98-115r0 - Sundry Minor Enhancements for SPC-2

ROWEBER at acm.org ROWEBER at acm.org
Tue Feb 10 15:25:32 PST 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* ROWEBER at acm.org
*
It appears that r0 of this proposal left plenty of room for improvement,
oh well it never was intended to be one of those 'passed on r0' things
anyway.

R1 will be along shortly.  This message attempts to respond to comments
received, indicating why or why not such comments have resulted in changes
between r0 and r1.  Please excuse the liberal application of cut and paste
on the comments received.  I'm trying to avoid an ad nausium 'he said' 'she
said' message.  If you want that, tune to CNN.

Gene's comment about requiring purchase of all standards resulted in the
following revised version of the text proposed under topic 1) [the general
requirement regarding truncated data].

   "If the information being transferred to the data-in buffer includes fields 
   containing counts of the number of bytes in some or all of the data, the 
   contents of these fields shall not be altered to reflect the truncation, 
   if any, that results from an insufficient allocation length value, unless 
   the standard that describes the data-in buffer format specifically states 
   otherwise."

This definitely restricts the list of standards that need be purchased.
However, it is only slightly shorter that the r0 wording.  I don't see
any good ways to make it shorter.

I was expecting some controversy regarding topic 2) [the sense-key specific
data for invalid reserved fields].  Gerry's comment that multiple-byte
reserved fields should be treated as an array of single bytes may very
well represent the opinion of the working group.  Actually, I am expecting
the working group to demand that topic 2) be dropped from the proposal.
In any case, changes in proposed wording for topic 2) are being deferred 
to the March meeting.  However, I will correct the table reference from 
36 to 63.

One comment suggested that reserved fields should not be checked.  This 
is a more restrictive requirement that currently appears in SPC.  Clause
3.3.7 contains the following statement regarding reserved field checking:

   "Recipients may check reserved bits, bytes, words or fields for zero values 
   and report errors if non-zero values are received."

Changing this to say that reserved fields should not be checked goes way
beyond anything in my proposal, and beyond anything I wish to propose.

Incidentally, the statement:

   "b) The contents of the sense-key specific data for the ILLEGAL REQUEST 
   sense key is not specified by SCSI-2 when the error occurs in a reserved 
   field."

is a quote from the minutes of the working group meeting where the sense-key
specific data was discussed.  Despite the fact that I wrote the minutes,
the statement does not reflect my opinion, or my intent in preparing the
current proposal.  I'm simply trying to clean-out the dust bunnies in the
SPC-2 closet.

The comments on topic 3) [the invalid op codes requirement] propose that
the r0 wording:

    "If a device server receives a CDB containing an operation code that is 
    invalid or not supported by that device server, target, or device, then 
    the device server shall return CHECK CONDITION status with the sense key 
    set to ILLEGAL REQUEST and an additional sense code of INVALID COMMAND 
    OPERATION CODE."

be changed to:

    If a SCSI device receives a CDB containing an operation code that is 
    invalid or not supported then
    CHECK CONDITION status with the sense key
    set to ILLEGAL REQUEST and an additional sense code of INVALID COMMAND
    OPERATION CODE shall be returned."

The line endings in the second version have been chosen to show where text
has been removed (or, infrequently, added).  I am not sanguine on the
change from "device server" to "SCSI device".  Device servers receive
commands and return status codes.  I have read SPC several times trying
to apply this definition consistently and I cannot make a proposal that
will have to be modified before insertion by the technical editor.
The other proposed changes will appear in r1.

Topic 4) concerns Note 53 and its suggestion for SCC virtual devices.  
Contrary to the comments received, the IEEE Tutorial has as one of its many 
topics, specific, detailed requirements for how SCC virtual devices should 
develop the unique IDs returned in the Device Identification VPD page.  The
ideas presented in the IEEE Tutorial conflict substantially with the vendor-
specific assignment described by Note 53.

Please note that topic 4) suggests the removal of Note 53, an idea
generally held as goodness by several in the working group.  Topic 4)
does not propose adding any text in place of the removed note.  Anyone
making IEEE unique IDs should be reading the tutorial and no specific
reference was thought necessary by whomever left this dust bunny in
the SPC-2 closet.

Somehow, topic 5) [the definition of the Identification descriptor field]
has gotten tangled up in the A/B port discussion.  The entire description
of the Device Identification VPD page avoids specific naming of ports.
In this regard, the description is trying to be fully compatible with
devices having two, three, or more ports.

The propose wording change simply tries to convey the fact that an 
Identification descriptor field can describe either a port or a device, 
and the Association field contents will tell you which.  This still may
not be ready for prime time, but don't ask the description of the
Device Identification VPD page to retreat from the multi-port capabilities
it already has.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com




More information about the T10 mailing list