the op x12 Inquiry standard is where?

Pat LaVarre LAVARRE at iomega.com
Tue Mar 12 15:33:00 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Pat LaVarre" <LAVARRE at iomega.com>
*
> T10 ... standards standardize exactly
> what they standardize, and nothing more.

So far so good.

> > > In my experience, the data returned
> > > by these commands is self-descriptive;
...
> The problem here is that
> you are applying the T10 standards
> at the wrong level of interface:

Ouch, I don't understand, I'm completely missing something here.

Where but T10 should I look for a standard governing what such Cdb's as:

        x 12 0 0 0 00 0
        x 12 0 0 0 05 0
        x 12 0 0 0 06 0
        x 12 0 0 0 24 0
        x 12 0 0 0 28 0
        x 12 0 0 0 FF 0

in fact do mean?

If and when some market leader makes the de facto standard radically different
|from the printed standard, who besides T10 will publish that fact in writing?

For a moment let's suppose reality is that the only op x12 Inquiry which has
to work is x 12 0 0 0 24 0, and that Cdb flatly has to copy in x24 bytes, but
a x1F at byte offset 4 in the data may be expressed as x00 or as x1F.

Don't all we in the T10/T13 community all lose together if noone is speaking
that truth out loud?

> > an op x12 Inquiry cdb ...
> > Microsoft ... zeroed bytes
> > include the byte at offset 4,
> > that T10 tries to say is the additional Length.
...
> What Microsoft (or Apple, or Linux, etc...)
> does at the software API interfaces
> have no necessary relationship
> to anything in any T10 document.

Very true.

> I'm sure that is you snoop the parallel SCSI, 1394, etc...
> physical bus you'll see the bytes you expect,

In my example, the drive identifies itself as an "QUANTUM", "FIREBALL SE4",
"API.".

I've been flatly assuming this is an Ata drive, not Atapi, with its Scsi
appearance being provided by a Microsoft "API" - is that wrong thinking? 
Should I be asking Quantum why in Windows they appear to be so creatively
interpreting op x12 Inquiry?

> Inquiry cdb to mean move in
> MAX(cdb[4], 0x24 - 8) bytes in,
> after moving in eight zeroed bytes.

Wrong, wrong, wrong, sorry.  After building some code to let me easily look
more closely, I see the reality is rather more like point 3 of this 6 point
algorithm:

1. Crash if cdb4 is zero, otherwise ...
2. Copy in min(cdb4, 8) zeroed bytes.  Thus zero the additionalLength at byte
offset 4 and agree no T10 Scsi standard is relevant at byte offset 2.
3. Copy in, to byte offset 8, x14 bytes of vendor & product identification,
such as "QUANTUM", "FIREBALL SE4", "API.", no matter the value in cdb4.
4. Copy data in no matter if the host asked to copy data out.
5. Report zero residue (i.e. all expected data copied) no matter how much or
how little data was copied.

Thanks again in advance.    Pat LaVarre



> RE: residue of 1394 Sbp-2 - forget it?
>>> Mcgrath, Jim 03/06/02 04:18PM >>>
* From the T10 Reflector (t10 at t10.org), posted by:
* "Mcgrath, Jim" <Jim_Mcgrath at maxtor.com>
*

Pat,

The problem here is that you are applying the T10 standards at the wrong
level of interface:

"I also see the Microsoft device on my desk that interprets an op x12
Inquiry cdb to mean move in MAX(cdb[4], 0x24 - 8) bytes in, after moving in
eight zeroed bytes.  Those eight zeroed bytes include the byte at offset 4,
that T10 tries to say is the additional Length."

What Microsoft (or Apple, or Linux, etc...) does at the software API
interfaces have no necessary relationship to anything in any T10 document.
Those standards standardize exactly what they standardize, and nothing more.
Traditionally this just means what goes across the parallel SCSI bus.  In
recent years other transport mechanisms (1394, ATA, Ethernet) have been used
to move around SCSI commands, data, and status.  Their common denominators
are all specified in the SAM (SCSI Architecture Model) standard.  None of
this has anything to do with what Microsoft drivers do, since that is not
the level at which they operate.

I'm sure that is you snoop the parallel SCSI, 1394, etc... physical bus
you'll see the bytes you expect, including in the case you cited the
additional length indicator.  If an upper level driver wants to hide that
|from other layers of software, then it certainly can - that has nothing to
do with T10, or even SCSI per se.

In the past there have been attempts to standardize higher layers of
software (e.g. CAM), but they met with limited market success.  Software
folks appear to be less inclined to agree to a common standard than the
hardware vendors.

Jim


-----Original Message-----
From: Pat LaVarre [mailto:LAVARRE at iomega.com] 
Sent: Wednesday, March 06, 2002 2:31 PM
To: sbp3 at isg.apple.com 
Cc: t10 at t10.org 
Subject: Re: residue of 1394 Sbp-2 - forget it?


* From the T10 Reflector (t10 at t10.org), posted by:
* "Pat LaVarre" <LAVARRE at iomega.com>
*
> David Wooten 03/05/02 03:11PM
> residual/residue count is ... command set

Good fun, thank you, we hold eye-poppingly different assumptions here.

Til I met 1394 Sbp-2, I had never met a storage protocol designed to be
completely unable to count bytes moved.

The device model I knew was close kin to the standard i/o of C where I saw
it first in 197X: you tell me how many bytes I may move, and I'll tell you
how many bytes I did move, or else I'll reject your request altogether.

This is the device model I see in generic UsbMass, in Dos/Win Aspi, in Win
Ioctl, etc. etc. etc.

I think we're now telling me 1394 Sbp-2 differs here from iScsi, UsbMass,
etc. etc. etc.   We're saying 1394 Sbp-2 by design flatly abandons this
traditional responsibility to count residues accurately, giving this duty
over to the (not likely) invention of new & improved command sets.

> Peter Johansson 03/05/02 03:54PM
> As long as the bridge ... moves the data
> and faithfully reports
> whatever the endpoint device
> has to say about residue

We agree then that Sbp-2 neglects to specify HOW to do this?

Let's suppose the raw device is Scsi, printer port Scsi, AtapiPio, or
UsbMass.

In any of those protocols, the device gets Two chances to comment on
residue.  Sure, the device can fail a cdb and provide auto-sense data.  But
also the device can merely cut the data transfer short.  In Scsi, the device
deasserts REQ.  In Atapi, the device deasserts DRQ.  In UsbMass, the device
reports nonzero dCSWDataResidue.

Now tell me how, as a bridge from 1394 to any of these others, how can I
faithfully pass back the fact that the device did cut the data short?

I see I could ignore the residue altogether.  I see I could alter the
passing status and fabricate auto-sense data.

I see no standard that tells me when to do either, nor what SK ASC ASCQ to
fabricate.

> Peter Johansson 03/05/02 03:53PM
> Commands typically fall into ... classes

Yes, though no standard identifies these classes.

> ... commands, such as disk READ or WRITE,
> for which GOOD status means
> that all the bytes were transferred.

All which bytes.

I see a bridge from 1394 can know if all of the data buffer did transfer.  I
don't see that a bridge from 1394 can know if transferring less than all the
bytes of the data buffer is in fact an error.

I don't (yet) have much data here ... anybody have an opinion over whether I
wrong to bet that most external 1394 hard drives built out of 1394 bridges
to Ata do Not consider nonzero residue to be an error?

> ... commands, such as INQUIRY,
> that may not make use of all the buffer space
> provided by the initiator
> even when they complete with GOOD status.
> In my experience, the data returned
> by these commands is self-descriptive;

Hmmm.

You mean to say "experience"?  Not just publications?  Actual behaviour of
actual devices available in mass?

I agree the texts at <http://www.t10.org/scsi-3.htm> have clearly claimed
for ages past, for example, that byte 4 of op x12 Inquiry data should
contain the additionalLength.

I also see the Microsoft device on my desk that interprets an op x12 Inquiry
cdb to mean move in MAX(cdb[4], 0x24 - 8) bytes in, after moving in eight
zeroed bytes.  Those eight zeroed bytes include the byte at offset 4, that
T10 tries to say is the additionalLength.

I like having a low layer of the i/o system tell me how many bytes moved.
That's the foundation on which I'm used to building layers that then make
sense of the bytes.  Myself having to count the bytes that move in, having
noone bother to count the bytes that move out, those ideas are new to me.

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