94-188r6 -- Proposed INQUIRY command enhancements

Ralph Weber -- VMS -- ZKO3-4/U14 weber at star.enet.dec.com
Sun Oct 30 13:29:28 PST 1994


                                                                  X3T10/94-188R6

To:         Membership of X3T10

From:       Ralph O. Weber
            Digital Equipment Corporation

Date:       October 30, 1994

Subject:    Proposed INQUIRY command enhancements


This document proposes a mechanism by which an application client can
determine what SCSI commands are supported by a device server and what
capabilities within those commands can be used.  Access to the data is
patterned after the vital product data pages in the INQUIRY command. 
The proposal takes the form of additions to the INQUIRY command.

The revision corrects two oversights that I discovered in revision 3. 
In revision 3, I failed to update the proposed text that describes
what a device server should do when it does not support the operation
code specified in the INQUIRY/CmdDt CDB.  Also, I failed to remove the
VSop=1 & StdOp=1 text for the case where data is not available from
the media.

In the printed copy, all differences from revision 0 (or the existing
SPC) are marked with change bars.

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?

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

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

If approved, these additions would appear in the SCSI-3 Primary
Commands standard.  Per direction from the X3T10 general working
group, support for these additions to the INQUIRY command shall be
optional.

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.

This proposal has the following advantages:

   +  No need to validate received reserved fields on main-line device
      server code paths,

   +  No mode page bits to manage device server checking/non-checking
      of reserved fields, and

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

Generally speaking, this proposal is modelled on the changeable
parameters mode pages.

The following text is proposed for inclusion in the SPC.  Where clause
and table numbers are used, they are taken from SPC revision 3 (dis-
tributed in the September/October X3T10 mailing).

Modify clause 7.5 to read (changes are marked with change bars):

7.5 INQUIRY command

The INQUIRY command (see table 18) requests that information regarding
parameters of the target and its attached peripheral device(s) be sent
to the application client.  Options allow the application client to
request additional information about the target or logical unit (see
7.5.3) and information about SCSI commands supported by the device
server (see 7.5.4).

                           Table 18 - INQUIRY command
+=====-========-========-========-========-========-========-========-========+
|  Bit|   7    |   6    |   5    |   4    |   3    |   2    |   1    |   0    |
|Byte |        |        |        |        |        |        |        |        |
|=====+=======================================================================|
| 0   |                           Operation code (12h)                        |
|-----+-----------------------------------------------------------------------|
| 1   |                           Reserved                  |  CmdDt |  EVPD  |
|-----+-----------------------------------------------------------------------|
| 2   |                           Page or Operation code                      |
|-----+-----------------------------------------------------------------------|
| 3   |                           Reserved                                    |
|-----+-----------------------------------------------------------------------|
| 4   |                           Allocation length                           |
|-----+-----------------------------------------------------------------------|
| 5   |                           Control                                     |
+=============================================================================+

An enable vital product data (EVPD) bit of one specifies that the
device server shall return the optional vital product data specified
by the page code field.  If the target does not support vital product
data and this bit is set to 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.

A command support data (CmdDt) bit of one specifies that the device
server shall return the optional command support data specified by the
operation code field.  If the device server does not support returning
command data and this bit is set to 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.  Details
of the command support data can be found in clause 7.5.4.

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

When the EVPD bit is one, the page or operation code field specifies
which page of vital product data information the device server shall
return (see 8.4).  When the CmdDt bit is one, the page or operation
code field specifies the SCSI operation code for which device server
shall return command support data (see 7.5.4).

The remainder of clause 7.5 needs no changes.

Add the following as clause 7.5.4.

7.5.4 Command support data

Implementation of command support data is optional.  The application
client requests the command support data information by setting the
CmdDt bit to one and specifying the SCSI operation code of the desired
CDB.

If the device server implements the requested SCSI operation code, it
shall return the data shown in table t1.  If the device server does
not implement the requested SCSI operation code it shall return the
peripheral qualifier and type byte followed by a byte containing 01h
followed by three zero bytes.

                     Table t1 - command support data format
+=====-========-========-========-========-========-========-========-========+
|  Bit|   7    |   6    |   5    |   4    |   3    |   2    |   1    |   0    |
|Byte |        |        |        |        |        |        |        |        |
|=====+==========================+============================================|
| 0   | Peripheral qualifier     |           Peripheral device type           |
|-----+-----------------------------------------------------------------------|
| 1   |                           Reserved         |  VSop  | StdOp  | Valid  |
|-----+--------------------------------------------+--------------------------|
| 2   |   ISO version   |       ECMA version       |  ANSI-approved version   |
|-----+-----------------------------------------------------------------------|
| 3   |                           Reserved                                    |
|-----+-----------------------------------------------------------------------|
| 4   |                           CDB size (m - 4)                            |
|-----+-----------------------------------------------------------------------|
| 5   |                                                                       |
|- - -+- -                        CDB usage bit mask                       - -|
| m   |                                                                       |
+=============================================================================+

The peripheral qualifier field and the peripheral device type field
are defined in 7.5.1.

If the Valid bit is one, the remaining data is as defined in this
standard.  If the Valid bit is zero, the remaining data is not present
or undetermined.  One possible reason for the Valid bit being zero is
the device server's inability to retrieve information stored on the
media.

If the operation code being tested is supported as defined in a SCSI
standard, the StdOp bit shall be one, the VSop bit shall be zero, and
the ISO, ECMA and ANSI-approved version fields shall contain standard
INQUIRY data naming the standard that defines the SCSI command. 
(Information about standard INQUIRY data can be found in clause
7.5.1.)  If the operation code being tested is supported in a vendor-
specific way, the StdOp bit shall be zero, the VSop bit shall be one,
and interpretation of the ISO, ECMA and ANSI-approved version fields
by the application client shall vendor-specific.  If the operation
code being tested is not supported, both the StdOP and VSop bits shall
be zero.

The CDB size field shall contain the number of bytes in the CDB for
the operation code being tested, and the size of the CDB bit mask
field in the return data.  The group code field in each operation code
defines the CDB length.  Except for group 6 and group 7 operation
codes, CDB lengths are defined in the SAM.  Where specified, the CDB
size field shall contain the value defined in the SAM for the
operation code group being processed.

      NOTE n1 The CDB size field is provided primarily for the
      convenience of the application client.  In most cases, the
      is known from the operation code group before the INQUIRY
      command with CmdDt set is sent.

The CDB usage bit mask field shall contain a usage map for all the
bits in the CDB for the operation code being tested.  The bits in the
usage map shall have a one-for-one correspondence to an actual CDB for
the operation code being tested.  If the device server evaluates a bit
as all or part of a field in the CDB for the operation code being
tested, the usage map shall contain a one in the corresponding bit
position.  If the device server ignores a bit in the CDB for the
operation code being tested, the usage map shall contain a zero in
the corresponding bit position.

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.




More information about the T10 mailing list