de facto obsolete sbc-2 ops - 8Bh
LAVARRE at iomega.com
Wed Feb 20 08:25:10 PST 2002
* From the T10 Reflector (t10 at t10.org), posted by:
* "Pat LaVarre" <LAVARRE at iomega.com>
> > Can we obsolete x8B?
> > On the theory that for some people
> > this will be the Seek op for 64-bit Lba's?
> "Elliott, Robert" <Robert.Elliott at COMPAQ.com> 02/19/02 12:51PM
> ... opcodes are a rare commodity;
> we don't want to discard them
> just because the lower bits match
> some other opcode's lower bits
> (SEEK(6) at 0Bh and SEEK(10) at 2Bh).
Somebody please elaborate?
I missed the whole why not carry Seek forward beyond 2TiB @ 0.5KiB/block discussion, back whenever it occurred?
I came to expect to see Seek(16) at x8B as follows:
1) I think I saw we Sbc folk have Read in 6, 10, 12, and 16 bytes forms at x 08 28 A8 88. I saw we have Write at x 0A 2A AA 8A. I saw we have WriteVerify at x 2E AE 8E. I saw we have Verify at x 2F AF 8F. In contrast to all this, I saw as yet we have Seek only at x 0B 2B.
2) I think I saw the significant distinction between the required x 28 2A and the optional x A8 AA goes commonly unused in a commodity PC. With x A8 AA we raise the max block count above xFF:FF, aye. But we don't raise the max expressible Lba and we don't alter the deeply regrettable fact that Wintel favours block counts of x00:80 and below.
3) The main point I saw in progressions like x 08 28 88 was to raise the maxLba expressible from x1F:FF:FF (1GiB @ 0.5KiB/block) to xFF:FF:FF:FF (2TiB) to xff:ff:ff:ff:FF:FF:FF:FF.
Thus I came to expect to see Seek(16) at x8B, for devices that store more than 2TiB @ 0.5KiB/block,
If people aren't putting Seek(16) there, where are they putting it? Out among the ops whose Cdb length's are less determinate? That's hard to credit: those ops are hard to transport across platforms.
> 16-bit opcodes are a rare commodity;
Somebody help me out with terminology here? I got lost in the "16-bit opcodes" part.
Unless corrected I'll take this English to mean to say that the ops x00..FF are a precious resource. Most precious are the ops that are not vendor-specific yet but still have long established Cdb lengths i.e. x00..5F A0..BF. Next most precious are the not vendor-specific ops of newly specified Cdb length i.e. x7F..9F.
I thought the original Scsi had "8-bit" ops but x7F is an escape op that gives us a fresh new "16-bit" op space aka the "service action" sub-op.
> opcodes are a rare commodity;
I count myself as a language lawyer. I find specs, I buy a copy of the official draft (I even have an official Scsi 1), I read the specs, I try to understand the specs ... all sometime before/as I code an implementation.
I haven't really "read" the Sbc docs - but on my first glance, it seemed to me that x8B was quietly left out.
I'm given to understand a lot of people in our business are less careful - which makes me think x8B is going to be Seek(16) whether we like it here or not. If that's true, then we'd do better to admit that up front than to try and patch up life later.
> opcodes are a rare commodity;
Maybe we should make x8B Vendor-Specific rather than Obsolete, so device folk get at least one 16 byte Cdb they can use for whatever purpose? I think I see the July 2001 rev 4 Sbc-2 makes vendor-specific only Cdb's of 6, 10, and indeterminate byte length?
> I count myself as a language lawyer
Courtesy <http://www.tuxedo.org/~esr/jargon/html/entry/language-lawyer.html> we know: ... 'A language lawyer is distinguished by the ability to show you the five sentences scattered through a 200-plus-page manual that together imply the answer to your question "if only you had thought to look there" ...'
But the t10 texts I don't (yet?) know well.
* 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