"reserved" means what, according to t10

JimMcGrath at oaktech.com JimMcGrath at oaktech.com
Mon Feb 3 12:59:52 PST 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* JimMcGrath at oaktech.com
*





Pat,

There was some confusion on this topic years ago, but that has not been the
case for years.  Essentially all T10/T13 standards use the following
words::

ATA: "A keyword indicating reserved bits, bytes, words, fields, and code
values that are set aside
for future standardization. Their use and interpretation may be specified
by future extensions to
this or other standards. A reserved bit, byte, word, or field shall be set
to zero, or in accordance
with a future extension to this standard. The recipient shall not check
reserved bits, bytes, words,
or fields. Receipt of reserved code values in defined fields shall be
treated as a command
parameter error and reported by returning command aborted."

MCC: "A keyword referring to bits, bytes, words, fields and code values
that are set aside for future
standardization. Their use and interpretation may be specified by future
extensions to this or other
standards. A reserved bit, byte, word, or field shall be set to zero, or in
accordance with future extension to
this standard. The recipient shall not check reserved bits, bytes, words or
fields. Receipt of reserved code
values in defined fields shall be treated as an error."

As you can tell, the wording is essentially identical.

So while the values should be set to zero by the sender (so that there is a
known, legacy value used), the recipient is NOT suppose to check it.  This
allows the sender to use the same values for recipients at various levels
of standards support.  However, it is up to the sender to recognize that
sending values to a recipient that does not support the feature will not
lead to the intended result.  The only exception for this is the reserved
command codes, which are checked by the recipient.

Note that hosts are well situated to determine what a device supports,
since the device typically indicates its standards compliance level in the
returned identification data.  Devices are not usually so blessed - it is
difficult for a device to determine what a host supports.

Jim




                                                                                                                                       
                      "Pat LaVarre"                                                                                                    
                      <LAVARRE at iomega.c        To:       <t10 at t10.org>                                                                 
                      om>                      cc:                                                                                     
                      Sent by:                 Subject:  "reserved" means what, according to t10                                       
                      owner-t10 at t10.org                                                                                                
                                                                                                                                       
                                                                                                                                       
                      02/03/2003 10:21                                                                                                 
                      AM                                                                                                               
                                                                                                                                       
                                                                                                                                       




* From the T10 Reflector (t10 at t10.org), posted by:
* "Pat LaVarre" <LAVARRE at iomega.com>
*
Eh?  What do T10 folk think "reserved" does mean?

The story I heard was as follows.  How inaccurate is
it?

I first grew curious when I saw Rob E say "defining
fields to be reserved generally means they must be
tested for zero", then more curious when I saw John P
disagree, so here I now am.

In talk like this before now, I think I've seen
different people come to different "of course"
conclusions near here.

Cluelessly, curiously, thankfully yours, Pat LaVarre

P.S. In five parts:

--- 1. Intro

The issue is how to let a command/reply protocol grow
over time.  That is, how do we ensure that old hosts
mostly work with new devices and that old devices
mostly work with new hosts.

By "host" here I mean an "initiator" of commands that
composes "Command Out" and "Data Out".  By "device"
here I mean a "target" that composes the "Data In" and
"Status In" of replies.  By "mostly work" I mean
"interoperate robustly".

As far as I know, Tcp/ip folk first spoke publically
of this issue in the January 1980:
http://www.ietf.org/rfc/rfc761.txt
[US] DOD STANDARD: TRANSMISSION CONTROL PROTOCOL
2.10.  Robustness Principle
... a general principle of robustness: be conservative
in what you do, be liberal in what you accept from
others

This principle says never set a reserved bit but do
always ignore the reserved bits set by others.

--- 2. "Reserved" means what where

I've been told much of the net works that way, though
I know I often see Ftp, especially firewalls, complain
of new protocol.

I've been told Ata (somewhat distinct from Atapi)
works that way.

I've even been told Scsi 3 works this way, having
changed from Scsi 2 ... I wonder how much I hear is
untrue?

--- 3. "Reserved" in Scsi 2 of the mid 1990's

Scsi 2, as far as I can remember, required the device
to be conservative in what it accepted: to burn some
of the valuable time between receiving a command and
acting on that command in checking reserved bits.

Implementations in silicon don't much care, they can
check in parallel.  But implementing devices in
single-cpu firmware/software often adds a time for
bit-checking serially inline to the overall "command
overhead" time lost between Status In and Command Out.

More time gets lost than you might imagine, in devices
where code space is expensive, because the more
compact ways of coding such checks take more time.

--- 4. "Reserved" when not peer to peer

I'm not sure if this Send Conservative, Accept Liberal
principle holds up well when not all hosts and devices
are created equal.

I know in Atapi I've seen new hosts from Microsoft
want old devices to understand such new bits as the
byte 7:8 BlockDescriptorLength in op x55 ModeSelect10
data.

Those bits are "new" if we remember they were
"reserved" in the SFF 8020i made prominent by
Microsoft's WHQL PC '9X specifications.

As far as I know, there is no usable protocol i.e. no
Microsoft-supported protocol, for the device to say it
doesn't understand the new bits.  There may be some
paper protocols.

Bottom line, Microsoft's new Atapi hosts don't just
plain work with those old devices.  Another
unfairness here is that some of these devices have
their code in Rom, or at least Otp.  The host could
change to cooperate, no matter how wrong the device
is, but changing the device involves economically
impractical physical disassembly & reassembly.

--- 5. Conclusion

Indeed I wonder:

What do T10 folk think "reserved" does mean?

Cluelessly, curiously, thankfully yours, Pat LaVarre

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list