"reserved" means what, according to t10

Pat LaVarre LAVARRE at iomega.com
Mon Feb 3 10:21:01 PST 2003


* 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




More information about the T10 mailing list