94-188r4 -- Proposed INQUIRY command enhancements

Bob Snively Bob.Snively at Eng.Sun.COM
Thu Oct 27 19:45:35 PDT 1994


Ralph,

I have one or two small suggestions about the introduction to the
proposal and one small suggestion about the actual proposal.  Aside
|from those, it looks fine to me.

Bob


>
>                                                                  X3T10/94-188R3
>
>To:         Membership of X3T10
>
>From:       Ralph O. Weber
>            Digital Equipment Corporation
>
>Date:       October 27, 1994
>
>Subject:    Proposed INQUIRY command enhancements (a.k.a TEST SUPPORT)
>
>

....

>
>Three issues are open for discussion at the November X3T10 Working
>Group meeting:
>
>  1)  Should the operation code and control bytes be included in the
>      INQUIRY/CmdDt returned data?
>

As I understand it, at present the size field is supplied instead
of the operation code.  That makes good sense.

The control byte validity should certainly be included in the returned
data.


>  2)  Should a CHECK CONDITION be returned instead of data with the
>      Valid bit clear?
>

I assume that this refers to the case where information is 
tested for a non-existent command.  I like the present definition
in section 7.5.4, which uses the Valid bit clear.  This is really
not a check, since correct information about the validity of
the command is being presented.


>  3)  Should the EVPD and CmdDt bits be joined to form a single two-bit
>      field?
>

I like the way it is specified now.  The only possible problem would be that you
have to specify mutual exclusivity, which you did very nicely in paragraph 3
of the document.

>
>This proposal is a response to the decision to eliminate the require-
>ment that device servers test all reserved fields for zeros.  Said
>requirement is present in the SCSI-1 and SCSI-2 standards, but has
>been dropped from the SCSI-3 standard, via a X3T10 approved change
>to the SCSI-3 Architecture Model.
>

Just a note here.  This is actually a response to the perceived
requirement that a host be able to determine what particular
standard (not reserved) options are supported by a device.  Just
because reserved bits are not checked (because they should never
be generated) does not mean that invalid patterns of standardized bits are
not checked.  That reduces the advantage list to one item:

>
>   +  No complex version-to-feature conversion tables (which eliminates
>      a significant source of errors in both the application client and
>      the device server)
>

Of course, the simplest mechanism for assuring proper behavior is to
use the simplest mandatory subset of SCSI possible for your application,
as recommended by the fibre channel profiles and similar documents.

>
...
>
>Modify clause 7.5 to read (changes are marked with change bars):
>
>7.5 INQUIRY command
>
...
>
>If both the EVPD and CmdDt bits are zero, the device server shall
>return the standard INQUIRY data (see clause 7.5.1).  If the page or
>operation code field is not zero when both EVPD and CmdDt are zero,
>the device server shall return CHECK CONDITION status with the sense
>key set to ILLEGAL REQUEST and an additional sense code of INVALID
>FIELD IN CDB.  

If I understand it correctly, the "unchecked reserved bits" discussion 
had intended that such undefined values simply be ignored by the
target.  That would eliminate the above check condition requirement.




More information about the T10 mailing list