This message is from the T13 list server.
[ BC [EMAIL PROTECTED] ]
> >>> Hale Landis 04/15/02 05:21PM >>>
PROGRESS!!! I feel you now share my pain. Welcome to my world.
> >On Mon, 15 Apr 2002 16:22:26 -0600, Pat LaVarre wrote:
> >This message is from the T13 list server.
> >Your error here is to think the Cdb is the whole "command".
> >Viewed in the light of the most basic precepts of computer i/o,
> >it isn't the WHOLE command.
>
> But it *is* the *whole* command,
No.
> it is the only thing most
> devices get from the host.
Yea, pretty rude that, eh? This is what happens in direct-attached parallel
Scsi, direct-attached Atapi, etc. ... hence the residue kluges of Microsoft &
friends. Scsi-over-Usb & Scsi-over-1394 by contrast do pass the whole command
across the bus.
> [The Cdb] fully defines what the device is
> expected to do including the direction
> of data transfer and the amount of data.
No. The Cdb definitely should, by the most elemental precepts of i/o
programming, but the Cdb actually doesn't say how many bytes to copy which
way.
Just because something should be, doesn't make it true. Not in the real
world.
> >To a classically trained programmer, what's bizarre about many
> >Scsi-over-whatever protocols, and T13 Atapi protocol in
> >particular, is that these protocols do not include in the
> >"command" a plain indication of how many bytes to copy which way.
>
> This is completely out of the context of the ATA/ATAPI interface
> and the actual bus transactions that happen as part of the
> command execution on the ATA interface.
No.
> This extra information is provided by host application programs
> to the host OS device driver stack as part of good software
> design, to insure system and application data integrity and so
> that the OS device driver stack is not required to fully
> understand every device command.
Yes. The Cdb does not plainly say how many bytes to copy which way.
> Even my ATADRVR software has
> these parameters in the reg_packet() function call (in file
> ATAIOREG.C).
Yes. This is UNIVERSAL. I have NEVER seen ANY Scsi-over-whatever Api that
was just:
int ...(void * cdb, void * data);
Instead people always include the dataLength and a pleaseIn direction flag of
some kind. Over time they learn to include the cdbLength and to return the
residue:
int ...(void * cdb, int cdbLength, void * data, int dataLength,
boolean pleaseIn);
> >As a device, all you get is the Cdb, in place of what you need.
> >So you're stuck patching up life afterwards.
>
> What more does a device need? Does a SCSI 00H command ever
> transfer data?
It's not fair of me to say this, but it's true and it makes a point for me to
be unfair, so ...
Yes, in fact op x00 TestUnitReady does sometimes copy data In. Some T10-ish
standard somewhere for optical stuff says sometimes it should - maybe an SFF
publication? (The Cdb -x 00 0 0 0 0 0 never does copy In data, AFAIK.)
Some people think the fact of op x00 sometimes copying data In is why some Cd
burning software has the legacy of sending a Cdb of op x00 with a nonzero -i,
a legacy which has been seen to cut Cd-rw burning speed from 6X to 2X when
using on Scsi-over-Usb1, which penalises you sharply in time when you
inaccurately forecast how many bytes a Cdb will copy.
> Is a SCSI 12H command ever a write command?
To my knowledge, the only form of op x12 Inquiry that works reliably is the
command -x 12 0 0 0 24 0 -i x24. Notice this command contains more than the
Cdb. It contains also the plain (but cryptic) indication `-i x24` to copy In
x24 bytes.
Change just that number, and this command stops working, back in the real
world.
> Is a SCSI 2AH command ever a read command?
Not to my knowledge.
> a write command .. a read command?
AFAIK in practice hosts get direction wrong only for vendor-specific ops. The
mechanism is usually an Api that leaves off the pleaseIn flag. At some layer
in the host, the pleaseIn flag is reconstructed by looking the op in a table,
a table which is correct for the most commonly used standard ops, but
incorrect otherwise.
> When does a Read 10 command tell a device to transfer
> more than N blocks of current_device_block_size bytes?
Hey, ho, let's watch the wiggle words appear.
Tell me please, what is the current_device_block_size? Noone can say, not
__plainly__.
For example, I've seen hosts poll for media to appear with the command -x 28 0
00:00:00:00 0 00:01 0 -i x200. This works fine if the block size of the next
media inserted happens to be 0.5KiB = x200 bytes. But if the block size is in
fact x800, we suddenly have a device asking to copy In x800 bytes to a host
that wants just x200. Ouch.
And we've beat to death the fact that the Cdb -x 12 0 0 0 05 0 often asks to
copy In 6 or 8 bytes rather than 5.
> If we believe what you say, then all commands result in random
> device activity. That would be nothing but chaos. But we know
> that isn't the way the world works.
Isn't it? (Sorry.)
> If we believe what you say, then all commands result in random
> device activity.
It's not RANDOM activity. It's LOOSELY correlated activity. Just a little
bit fuzzy. Not too fuzzy to tolerate, when you're paid to care.
> >Because "everyone knows" the Cdb does not plainly indicate how
> >many bytes to copy which way.
>
> Good grief. Why has T9, T10, t13, etc, spent all these years
> defining all these CDB values?
I have no idea.
I don't think you've ever seen any employer of mine invest a lot in those
committees - not at the Cdb level?
I do recommend investing time in T13 Atapi, which works out a command does,
not just what a Cdb might do. Ditto for T10 when they talk about what
commands do in other forms of Scsi-over-whatever
> [...]
Here I deleted some metadiscussion without comment.
> If any given CDB is nothing more
than random data that can be ignored then what is the point of
having industry wide specifications and standards?
Actual standards are more or less credible.
Credible standards are useful. A subset of T10 is credible. "Everyone knows"
more or less what that subset is.
For example, T10 correctly states that -x 12 0 0 0 24 0 -i x24 copies In x24
bytes in which the bytes at offsets x8..F name the vendor and the bytes at
offsets x10..1F name the product. T10 less plainly says a lot of other stuff
that has less credibility. For example, T10 says the Cdb -x 12 0 0 0 00 0
copies only Status in, no Data bytes, and avoids disturbing any pending unit
attentions. If you know your device supports this, this is a cool
are-you-there ping to have available. But devices generally choke if you try
this. That's reality.
Device designers can and do compete on implementing more than the credible
subset of T10. I have myself shipped devices with no known bugs at the T10
level. I like to believe this makes them interoperate better with Windows
over time, with boot Bios, with Apple, with Linux, ....
> You have your own definition of SCSI
and that doesn't seem to match the rest of the world.
My definition is real. My definition is public. My definition works. These
are strengths.
Having T13 people make fun of my English is a weakness. I'm working on
improving my English.
I think here now you understand the reality I'm describing. If you want to
continue to say that much of what makes things really work is not a T13
concern, then certainly I can't stop you.
The bottom line is that with Microsoft Windows AtapiPio works and AtapiDma
doesn't, when you're trying to copy a count of bytes not evenly divisible by
four. That's a powerful fact. And it's growing. A few years ago, only
counts not divisible by two were broke.
A few years from now, we can imagine counts not divisible by eight will break
- except for the popularity of the command -x 12 0 0 0 24 0 -i x24. It will
be fun to watch those two traditions battle for supremacy ... I hear already
significant numbers of Scsi-over-1394 devices don't support the op x12 Inquiry
command directly. These devices work only if the host folk have a filter
driver in place to support a op x12 Inquiry constructed out of cached 1394
plug 'n play data, without bothering the device.
x4402 Pat LaVarre [EMAIL PROTECTED]
http://members.aol.com/plscsi/
