[t10] 13 cases in bus annex why how

Pat LaVarre LAVARRE at iomega.com
Mon Mar 17 19:36:29 PST 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* "Pat LaVarre" <LAVARRE at iomega.com>
*
P.S.
 
The fact that the 13 Cases taxonomy often is useful doesn't mean that other taxonomies aren't ever useful.
 
For example, another data taxonomy that often makes sense begins (1) transfers of block data between media and host via device, (2) transfers of byte data between device and host, (3) transfers of "long block" data e.g. data + ECC between media and host via device, (4) ...
 
But in USB, ideally these cases do not differ.  Indeed, Mass Storage would fit better into USB if we say the device always shall copy precisely the count of bytes the host wants to copy in precisely the direction the host likes, and let the Status copied In complain of any H vs. D disagreement.  But to make a USB like that work like legacy SCSI/ATAPI, the host has to double-buffer, which is something the host folk weren't good at doing, in 1998 when we wrote the USB specs.  So, given that we're not going to make the host double-buffer, well, then we needed a way of counting data bytes accurately.

	-----Original Message----- 
	From: Pat LaVarre 
	Sent: Mon 3/17/2003 8:06 PM 
	To: t10 at t10.org 
	Cc: 
	Subject: RE: [t10] 13 cases in bus annex why how
	
	

	Here we have 241 lines.  Can this be helpful?

	> Why does T10 want to know more of the 13 cases and
	> what is it that we want to know?

	Offline kindly I'm informed "why 13" is at least of
	idle interest here.  Here's a try at answering that,
	on the chance that that is the question intended.

	Somebody please tell me how clear I now am or am not?

	The short answer is we say 13 because 13 works.  We
	haven't worked too hard on explaining why 13 works. We
	just see that 13 does work.

	I imagine why 13 works is hard to understand because
	13 is a rhetorical & political choice.  It's a
	technical choice only by way of being an expository
	choice.  You could explain this same stuff in any of a
	thousand ways.  But as steep as this learning curve
	is, seemingly it is the flattest of the learning
	curves yet discovered near here.

	Saying 13 can deeply annoy people who want to be
	persuaded a case matters before they willingly allow
	the case to appear in an outline.  Saying 13 is a way
	of covering all the possibilities up front and
	deferring the discover of  which matter til later,
	deeper in.

	Saying 13 can also annoy people who build improperly
	layered devices - because they often get many of the
	13 cases wrong, differently at least by op, if not
	indeed differently by Cdb.

	But if you really want the long answer ...

	> ...

	All of us commonly say a host passes thru the CDB to
	the device and asks to copy bytes.  A host asks to
	copy In Hi bytes, or to copy Out Ho bytes, or copy no
	(Hn) bytes.

	So far we have 3 cases, not 13.

	So far so good, right?

	> ...

	"The Thirteen Cases" is an arbitrary convention for
	the next level of that same outline.  We go on to say,
	in reply, the device asks to copy In Di bytes, to copy
	Out Do bytes, or to copy no (Dn) bytes.

	Two parties each independently making a choice among
	three options gives us 3 x 3 = 9 cases.  But then when
	the host and the device happen to agree over which way
	to copy data (In, Out, or Not), then still they may
	disagree over how many bytes of data to copy.  Adding
	Di < Hi, Do < Ho, Hi < Di, Ho < Do gives us 4 more
	cases, for a total of 13 = 9 + 4.

	Clear, so far?  Arbitrary, maybe, but clear, right?

	> ...

	Having hit upon an outline of 13 sections, we stuck to
	our outline of "The Thirteen Cases" purely for
	expository reasons.

	First, thirteen cases is enough to persuade managers
	etc. to delegate the understanding of this detail to
	those folk who happily involve themselves in the
	grungiest of technical details.  Less is not better.
	If you force us back to say, just three cases, we'll
	end up including in our discussion people unwilling to
	invest the considerable time it takes to understand
	these real interoperability issues properly.  That
	won't help.

	Second, the number thirteen connotes evil in American
	English, which fits for anything outside of the "thin
	diagonal" cases of (Dn = Hn, Di = Hi, Do = Ho). The
	phrase "thin diagonal" makes visual sense if you draw
	the H vs. D matrix conventionally.

	"Evil" well describes the "positive residue" cases of
	(Dn < Hi, Di < Hi, Dn < Ho, Do < Ho): these cases
	often hang DMA engines.

	"Evil" even more faithfully describes all the
	remaining cases i.e. the "phase error" cases.  For
	those cases, all we ask is that timeout & reset &
	retry work as well as they ever do.

	Note we propose T10 not try to stray from the D = H
	thin diagonal.

	Ok, ok, maybe more often acknowledging this limited
	scope explicitly could help people properly apply our
	intentionally incomplete T10 specifications. But
	that's a worry for T10 folk.

	The issue here now is that T10 folk are asking USB DWG
	folk to explain something of USB to T10, not to grow
	the scope of T10.  Clearly the scope of USB DWG is
	more narrow: it is just USB.  Yet the scope of USB DWG
	is more broad: it covers the 13 cases, not just the 3
	of the thin diagonal popularly assumed in misreadings
	of T10 paper.

	How we quickly say only the significant bits of all
	this in a T10 appendix is the issue, right?

	> > less cases

	People do commonly write the first level of the
	outline by dividing the thirteen cases into just the
	three columns: Hn, Hi, and Ho.

	Indeed, sometimes all we say for Hn is how to copy CDB
	Out and Status In, so that in Hi and Ho we can take
	those as given and focus on Data In and Data Out.

	Surely you've seen pr*prietary chipset doc written
	this way?  First an Hn example, then an Hi example,
	then an Ho example?  Me, I've never seen chipset doc
	written any other way.

	> > more cases

	We could add the fourteenth case of Do = Ho = 1.  Its
	evil is well known: seen broken in chipsets, in Win
	Ioctl, etc. etc.

	But back in the real world, in practice, thirteen
	cases works.  If we divide the discussion into
	thirteen cases, we get true answers.  By
	distinguishing Dn and Hn, by acknowledging the
	inconvenience of D != H, by making the horror of H < D
	and Di != Ho and Do != Hi explicit, we give those
	cases proper attention.

	Within a section like Do = Ho, we can manageably
	subdivide the discussion.  Maybe we talk about Do = Ho
	= 1.  Maybe we talk about Do <= Ho when Do isn't a
	multiple of 8.  Whatever.  That's the third level of
	the outline - as yet, we have no expository
	conventions there.

	For transports that choke over such wildly creative
	approaches as not always copying multiples of 8, often
	in the Ho third of the document we just refer back to
	Hi. But sometimes only Ho is broken, as in Do = Ho = 1
	being broken while yet Di = Hi = 1 works.

	> ...

	Want to see four strawpeople go down in flames?

	1) Yes, in theory, on paper, in merely public
	specifications, the H and D choices are not
	independent.  In theory, the mutual observation of the
	sequence of CDB's leading up to a CDB gets the host
	and the device into agreement over which way to copy
	data and a max count of bytes to copy.

	Meanwhile, back in the real world, we have two state
	machines, one in the host, one in the device, so by
	definition they fall out of sync now and then, of
	course.  The question is not why do they fall out of
	sync.  The question is why don't they fall out of sync
	more often.

	For example, we get hosts that implement SFF/ ANSI MMC
	connected to devices that implement ANSI SPC, whoops.

	2) Yes, often the protocol for Hn is an extreme case
	of Hi or Ho, but sometimes it's not.

	For example, in ATA PIO, Hn is the extreme case of Ho,
	which differs from the unused extreme case of Hi.

	3) Yes, in theory, the host and device choose just as
	independently how many CDB and Status bytes to copy.

	Back in the real world, i.e. in actual bus traces of
	Microsoft Windows, the host & the device don't fall
	out of sync often enough on those for us to bother
	specifying a fix.

	Mind you, as we speak, the Usb Mass CWG is touching on
	the CDB length issue, with the latest proposal being
	to allow the host to round up to 12 from 6 or 10 at
	will.

	4) Yes, in theory, hosts other than Microsoft Windows
	matter ... but on this issue they agree.

	Linux, Mac OS X, other free BSD, BIOS, etc. etc. i.e.
	all the actual host source code seen by Us all solve
	this same problem this same way.

	The app on the host that authors the CDB passes the
	CDB thru together with a guessed length and a max
	length and a direction of how many data bytes to copy.

	Hosts vary in how distinct this info is e.g. some say
	guessed = max and some let a lower layer guess
	direction from op, but in the end at the bottom some
	piece of host code gets told max length and direction,
	separately from the CDB and independently of how the
	device parses the CDB.

	> the H vs. D matrix conventionally

	We never really figured out whether to write H then D
	or D then H.  Nowadays maybe I incline towards writing
	D then H, by the idea that H is expected and D is
	actual that drives the source code convention of
	writing the actual on the left e.g. { if (x == 42) ...
	} rather than { if (42 == x) ... }.

	> ...

	Anybody read this far?

	I trust we agree we don't want to put all this into a
	T10 appendix.

	Anybody know what we do want to say?

	If we think we're going to relate T10 to Usb Mass, I
	figure we have to mention "The Thirteen Cases".  That
	second-level outline is the core of the chapter 6 of
	Usb Mass that details the protocol. If you don't
	understand the outline, you won't properly understand
	the spec.

	Cluelessly, curiously, thankfully yours, 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