Proposed INQUIRY command enhancements

Ralph Weber -- VMS -- ZKO3-4/U14 weber at
Sun Oct 30 13:28:41 PST 1994


To:         Membership of X3T10

From:       Ralph O. Weber
            Digital Equipment Corporation

Date:       October 30, 1994

Subject:    Proposed INQUIRY command enhancements

This revision contains only comments and responses regarding
X3T10/94-188r3.  Or, was that 94-188r4.  As some of you may have
noticed, 94-188r3 was distributed and filed on the SCSI BBS as
94-188r4.  Sorry, Larry.

The next draft of this proposal will be found in X3T10/94-188r6.  This
document has been prepared to archive the discussion generated on the
SCSI Reflector by X3T10/94-188r3(4).

None of the comments I received changes my plans for future work on
94-188.  Some of the comments offer fuel for various opinions that
will be discussed at the November X3T10 Working Group meeting.  But,
I have no plans for revisions on the open issues until after the
Working Group meeting.

The reason for the 94-188r6 revision is an oversight on my part.  I
forgot to update the "what to do when a command is not supported" text
to reflect the new INQUIRY/CmdDt response data format.

I received three comments regarding 94-188r3(4) -- Proposed INQUIRY command 
enhancements.  This message responds to all comments.

Responses to comments ----------------------------------------------------

Brent Skinner wrote:

> Mr. Weber,
> You may hate me for this, but I still think the opcode should be
> the first byte in the reserved bit mask. My reasoning is as follows:
> 1) If the first byte is FFh then ANY command could be ANDed with this
> bit mask and the host would have no way to verify that it was really 
> the bit mask field that applied to this particular command. If the
> first byte was actually the opcode at least a comparison could be 
> made prior to its application. The intent of a bit mask is to show
> the valid bits for this command, in the case of the 12h opcode,
> there are only 2 valid bits, not eight.
> 2) In the event that an initiator has already placed the opcode
> in the inquiry CDB, overlaying this opcode on the command that it
> was intended for would have no detrimental effect.
> 3) Placing the opcode into the first byte would make the return data 
> more readable. This is demonstrated in the mode pages, where the page
> code is returned within the returned data.
> Similar to the mode sense command, would it be desirable to have a
> supported commands page which just lists all supported command
> opcodes...perhaps a VPD page? Then the initiator would know before 
> requesting a bitmask for a command whether it was supported or not.
> Thanks for your time,
> Brent Skinner
> <skinner at>

I see that you were proposing a behavioral change, as opposed to
noting an error in the example.  To me, only your bullet 3) offers
any sound reason for altering the simplicity of the INQUIRY/CmdDt
response data format.  However, as promised, I will put this issue
to a discussion and straw poll at the X3T10 November Working Group 
meeting.  I will revise the proposal to do whatever is most
acceptable to the Working Group.

Hans Ridder wrote:

% >This proposal has the following advantages:
% >
% >   +  No need to validate received reserved fields on main-line device
% >      server code paths,
% Doesn't this just change the problem from the main-line device server code
% path checking for reserved fields to the client main-line code path
% checking for the various supported options?
% I must be missing something....
% -hans

It boils down to a matter of trust and performance.  If the device 
server must validate reserved fields, then it must do that on every 
command it processes.  That is a constant performance drain.

The application client, on the other hand, needs to check for what
options it can use only once.  Then, the application client can send
correctly formed commands, the device server can assume that no
reserved fields are used, and a performance bottle-neck disappears.

Bob Snively wrote:

& >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.

The current proposal says that FFh is always returned for the operation
code field in the CDB.  But, if the Working Group prefers something else,
I will change it.

& >  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.

Actually, the concern here is for device servers that store their
INQUIRY/CmdDt data on the media.  What shall such servers do when
the media is not accessible?  Again, I await the Working Group's

& >  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.

Thanks for your support.  :-)

& >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.

I believe that the reserved field checking offered a reasonable
form of "which standard version" checking capability.  I admit to 
having stated my opinion as a point of fact.  My belief in this
regard is strong enough that it looks like a fact to me.

In any case, the text in question is introductory in nature.  
It will never become part of the SPC or any other X3T10 dpANS.

& >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
& 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.

Revision 3 of the SPC (and SCSI-2) contains the following paragraph:

      "An EVPD bit of zero specifies that the device server shall return the
      standard INQUIRY data.  If the page code field is not 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."

I thought that expanding the concept to cover both EVPD and CmdDt was the
appropriate thing to propose.

More information about the T10 mailing list