residue of 1394 Sbp-2 - forget it?

David Wooten wd at
Wed Mar 6 14:53:02 PST 2002


A few responses below.

David Wooten

> -----Original Message-----
> From: sbp3 at [mailto:sbp3 at]On Behalf Of Pat
> LaVarre
> Sent: Wednesday, March 06, 2002 2:31 PM
> To: sbp3 at
> Cc: t10 at
> Subject: Re: residue of 1394 Sbp-2 - forget it?
> > 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.

DRW: Well, I had the unfair/unfortunate advantage of having been at the
SBP-2 meetings where we spent a long time arguing about what the heck SBP-2
is supposed to be.  We concluded that it wasn't a storage protocol.  It is a
protocol to be used to encapsulate other protocols that didn't support
memory semantics.  1394 allows devices to move data directly to/from system
memory.  SCSI doesn't.  So, we put the (insert favorite device command
protocol here) commands inside a wrapper that adds the memory semantics and
some other, 1394 related stuff.  Clearly, SPB-2 can be used as a storage
protocol, but it can also be used for other things.  If keeping track of the
number of bytes moved as a result of an encapsulated command then the status
structure is more than capable of providing a place to put that information.

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

DRW: Your historical perspective is interesting, but, given that SBP-2 isn't
intended to be a protocol for controlling mass storage, I don't think that
it was a cop-out to not include the residual counts.  There are applications
for which the notion of a residual count has no useful meaning.  Either the
command completes or it doesn't. Also, although someone decided to use the
development of SBP-2 as an excuse for creating RBC, I don't think that new
command sets need to be invented to make SBP useful.  What does, however
need to happen is that someone needs to sit down and map those command sets
onto the different transport layer to figure out how things like residual
are going to be reported.  I thing that this is not an uncommon thing in the
industry.  I may be wrong but I think that you will find that SBC and ATA
have a lot in common, status reporting not being one of those things in
common.  The command set is easy to move between different transport media,
status isn't so easy and needs to be addressed separately.

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 sbp3"

send email to requests at with subject "help"

More information about the T10 mailing list