residue of 1394 Sbp-2 - forget it?

Pat LaVarre LAVARRE at
Wed Mar 6 14:31:21 PST 2002

> 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 =

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 =

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;


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

I agree the texts at <> 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

SBP-3 protocol for FireWire Mailing List
send email to requests at with subject "unsubscribe sbp3"

Set to Digest Mode:
send email to requests at with subject "subscribe digest =

send email to requests at with subject "help"

More information about the T10 mailing list