94-188r1 -- Proposed INQUIRY command enhancements (a.k.a. TEST SUPPORT)

Ralph Weber -- VMS -- ZKO3-4/U14 weber at star.enet.dec.com
Wed Oct 26 18:24:51 PDT 1994


I received four comments regarding 94-188r1 -- Proposed INQUIRY command 
enhancements (a.k.a. TEST SUPPORT).  This message responds to all comments.
I will be revising 94-188r1 in the next day or two.  As of this writing, I 
believe that one more short working group discussion will be necessary before 
this proposal can be sent to the Plenary for a vote.

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

>>>>>>>>>>>>>>>>>>>>
Brent Skinner wrote:

> Mr. Weber,
>
> I'm not a member of X3T10, but I have a question on your proposal. In
> it you state:
>
>> Thus, the CDB usage bit map for the INQUIRY command for a device
>> server that implements command support data but not vital product data
>> would be: FFh, 02h, FFh, 00h, FFh, 07h.  This example assumes that the
>> SAM defines uses for only the low-order three bits of the Control
>> byte.
>
> Wouldn't the bit map really be 12h, 02h, FFh, 00h, FFh, 07h?
>
> Brent Skinner <skinner at sector.kodak.com>

The only difference between the proposal and the comment is in the first byte. 
94-188r1 has a FFh in the first byte, the comment has a 12h.

I believe that 94-188r1 is correct.  If the device server checked only the 
bits identified in the 12h mask, then all of the following opcodes would be 
interpreted as being INQUIRY commands

   13h (bit 0 is set, but that's not in the tested bits mask), 
   16h (bit 2 is set, but that's not in the tested bits mask),
   1Ah (bit 3 is set, but that's not in the tested bits mask),
   32h (bit 5 is set, but that's not in the tested bits mask),
   52h (bit 6 is set, but that's not in the tested bits mask),
   92h (bit 7 is set, but that's not in the tested bits mask),
   93h (bits 0 and 7 are set, but they are not in the tested bits mask),
   97h (bits 0, 2 and 7 are set, but they are not in the tested bits mask),
   etc.

The operation code is a value not a bit mask.  So, the device server tests 
it as a field.  All of the bits in the field are tested in order to determine 
what the operation code is.  So, the bit mask of bits evaluated in the opera- 
tion code byte is FFh, not 12h.

Note: Another comment (discussed later) suggests dropping the operation code 
byte from the returned data.  After all, that byte of returned data always 
must be FFh.  So, no real information is conveyed by its presence in the 
returned data.


%%%%%%%%%%%%%%%%%%%%
Jeff Williams wrote:

%> This proposal has the following advantages:
%>
%>    +  No need to validate received reserved fields on main-line device
%>       server code paths,
%
% There is no need now.  We voted down reserved field checking.  Of course,
% robust firmware will still check anyway :-)
%
%>    +  No mode page bits to manage device server checking/non-checking
%>       of reserved fields, and
%
% We voted this down also :-)

I know that these two ideas were voted down.  I just trying to remind you all 
of the terrible previous proposals (:-)) that this proposal is trying to be 
better than.  By doing so, I am hoping to generate a landslide of popular 
support for this terrific idea.  :-)

% {Regarding table t1}, one thing I don't like about this format is that the
% current Inquiry pages all follow a specified format.  The first byte is the
% Peripheral Qualifier and the Peripheral Device Type.

This comment is well taken.  I will revise the proposal to include the 
Peripheral Qualifier and the Peripheral Device Type in the first byte of 
the proposed Inquiry return data format.

% {Regarding table t1}, I also think that a third bit should be added which
% would be used to indicate that the data cannot be returned at this time. 
% Using VSop and StdOp is not very obvious.  Another bit would be better.

Again, Jeff's point is quite valid.  I was bit hacking.  I will revise the 
proposal to signal the unavailability of data using a separate bit.

% {Regarding the StdOp & VSop bits}, Can't these be shrunk into one bit -
% OpSupp.  That is, the opcode indicates whether or not this is a VU.  
% Support of the command is the only item that is required.  Is your intention
% to allow a VSop bit to be settable for, say a 08h or 0Ah (read/write)?  

I was influenced by table B.2 (in Annex B of the SPC, rev 2 or 3).  This table 
shows that a given operation code is vendor unique for some device types and 
mandatory or optionial for others.  For example, operation code 05h (READ 
BLOCK LIMITS) is mandatory for tapes and vendor unique for disks, printers, 
processors, WORM, RO, and medium changer devices.

Certainly, as the 94-188r1 proposal goes, the StdOp and VSop bits are needed. 
However, the need results from the lack of device type information.  One can 
argue that the combination of operation code and Device Type (which will be 
added as proposed above) would be enough to know whether support is vendor 
unique.

Still, it would be a lot simpler to keep the StdOp and VSop bits.  At a 
minimum, keeping the bits would relieve host software from the need to keep 
all or several columns of SPC table B.2 in it's code sources.

% {Regarding the CDB size field}, this is only needed for VU commands.  
% I think using it for non-VUs is acceptable, but let's not imply that a 
% 10 byte 06h is allowable.

I will added a note regarding this fact.  In effect, the note will say that 
the CDB size field is present for the convenience of application clients that 
parse the returned data.  After all, that's the truth.

% I would ignore the control byte and the opcode byte.  An alternative to
% this may be to put the actual opcode in the first byte since this is the
% only supported value.  The reason I say this is that we have bit masks for
% fields we support that are used for the "middle part" of the command.  It
% would be nice to use these bits.

I agree that the bit mask for the operation code byte is useless (always FFh) 
and that the bit mask for the control byte is a constant for all operation 
codes (and probably not very informative).  Removing the operation code and 
control bytes from the Inquiry returned data will complicate the wording.  As 
such, the change violates the KISS principle.  On the other hand, this could 
easily be a trade-off between simplicity in the standard and simplicity in the 
device server implementation.

Speaking as a host implementor, I can work with either option.  Speaking as 
the proposal author, I would not like writing the more complex description 
only to have it killed by a Working Group vote.  Therefore, I beg your 
indulgence while I set this issue aside for discussion and straw poll at 
the November X3T10 Working Group meeting.


&&&&&&&&&&&&&&&&&
Ancot Corp wrote:

& A couple of suggested enhancements to the *new, improved Inquiry Command*:
& The section that explains what to do if both bits are off doesn't say 
& which is the offending field. Please add words to the effect that the 
& Field Pointer Bytes of the sense data shall point to the page code field.
&
& The section that explains what to do if both bits are off also doesn't 
& say which is the offending field. In this case it could be either of the 
& CmdDt or VPD bits. I suggest words to the effect that the CmdDt field is 
& the offender. I would also suggest that this section be a separate 
& paragraph.

I can find no other examples in the SPC where the contents of the sense-key 
specific data is defined when the ILLEGAL REQUEST sense key is called out.  
Being somewhat new to the SCSI world, I cannot be certain why this practice 
is followed.  However, I would speculate that it is based on the optional 
nature of sense-key specific data.  In any event, I am reluctant to set a 
precident for specifying sense-key specific data in this proposal.

& For the case where the data is unavailable due to media access problems, 
& I would suggest Check Condition, Sense Code of NOT READY (02), ASC of 
& Logical Unit Not Ready (04) and the appropriate ASCQ (00, 01, 02 or 03).

My proposal is influenced by the following statement from note 11 in SPC 
revision 3 (page 29):

    "If the device server does store some of the INQUIRY data on the
    media, it may return zeros or ASCII spaces (20h) in those fields
    until the data is available from the media."

Using this as a guiding principle, I believe that returing some data is per- 
ferrable to returning a CHECK CONDITION when the data is not available.  As a 
host software writer, I know that a CHECK CONDITION is treated as a much more 
serious event than receiving data that is not totally valid.

However, this case might be different from that of other INQUIRY data.  Thus, 
I propose to set this comment aside for discussion and a straw poll at the 
November X3T10 Working Group meeting.

% As a separate idea, suppose the device supports both standard and vendor 
% specific implementations, depending (for example) on a mode page bit. 
% Couldn't that require setting both VSOp and StdOp to 1?  Or does the 
% device return whatever the current setting is?

I do not see how the device server could return anything other than the 
current setting.  Beyond that, I am opposed to discussing such ill-formed 
device servers in this proposal.  I will not be a party to encouraging such 
degenerate behavior.


********************
Gerry Houlder wrote:

* 1) There isn't any wording that says what to do if the EVPD bit and CmdDT
* bit are both set. This should be an illegal state. I suggest that these two
* bits be made into a field that is described as follows:
* 
*     00 - Return standard Inquiry data
*     01 - Return VPD page data (optional)
*     10 - Return Command support data (optional)
*     11 - Illegal.
* 
* This scheme provides clearer guidance on how to handle the '11' state. I
* used the word "illegal" instead of "reserved" to show that this state gets
* rejected with Illegal Request sense even if reserved fields aren't checked.
* If the committee is ABSOLUTELY SURE that no one would think that a '11'
* value should be ignored if we put "reserved" there, then I would agree.

There is wording that says what to do if the EVPD bit and CmdDT bit are both 
set.  That wording reads as follows:

   "If both the EVPD and CmdDt bits are one, 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."

The proposal to agglomerate EVPD into a new two-bit field with CmdDt would 
give the INQUIRY command a new format.  Although the new format is upward 
compatible with the SCSI-2 format, that fact would not be immediately obvious 
to someone reading the SCSI-3 Primary Commands document.  This could cause 
significant confusion among those SCSI implementors who are not "lucky enough" 
to attend X3T10 meetings.

For this reason, I am reluctant to change the proposal as described in this 
suggestion.  However, there are already two issues that need discussion and 
a straw poll at the November X3T10 Working Group meeting.  I am happy to make 
this a third issue.

* 2) I think the VSOp and StdOp bits should become a 2 bit field in similar
* fashion, due to the sneaky addition of a special meaning to the '11' state
* of these bits. Ralph seems to have them defined as follows:
* 
*     00 - Requested Op Code is not supported
*     01 - Requested Op Code is supported as defined in SCSI Standard
*     10 - Requested Op Code is supported in a vendor specific way
*     11 - Command support data not yet available.
* 
* I think that changing these bits to a field like this adds greatly to
* understanding the available functions.
 
I am going to revise the proposal based on Jeff Williams' suggestion of a 
separate bit that indicates valid data.  I believe that making Jeff's change 
eliminates the problem discussed here and eliminates the need to make the 
change proposed here.

* 3) There needs to be more description of the "ANSI approved version" field,
* at least.  What version of which documents?  Should there be separate fields
* for SPC, SBC documents (for block command devices)?  The definition of the
* second document needs to be dependent on the SCSI device type.  It may not
* make sense to use the same field here that is reported in Standard Inquiry
* data because that data may not be useful enough.  This area needs to be
* discussed at the next working group meeting.

I will be happy to stand in the front of the room and act as bullseye for such 
a discussion at the November X3T10 Working Group meeting.  However, I will ask 
John or Larry to put a time limit on the discussion, since I think that the 
issue is beyond practical resolution.  (Who knows!  Maybe I can get a 
nomination for the George Penokie Glutton For Punishment award.)

However, please be aware of the following.  I will NOT link voting on 94-188r? 
to resolution of the ANSI-approved version question.  I will not allow 
94-188r? to be used as a vehicle for resolving the ANSI-approved version 
question.  Jim McGrath already has a document proposing to solve that problem. 
And, I wish Jim all the luck in the world on his proposal.




More information about the T10 mailing list