This message is from the T13 list server.
... turns out that during the last T10 meeting I discovered that I have to pass the transfer length in the CDB ...... Two comments on T10/04-262r3:
1. My linux implementation also finds itself needing to be told the direction of DMA operations ... also ... transfer length
Nothing new under the sun, aye. In the jargon of the 1999 usbmassbulk_10.pdf for SCSI over USB "Table 5.1 - Command Block Wrapper " and "Table 5.2 - Command Status Wrapper ", ...
A most to least vital order of info for the pass thru might be roughly:
bCBWCB = the opcodes and its parameters
bCSWStatus & x03 = pass, fail, and other
bmCBWFlags & Direction = expected data transfer direction
dCBWDataTransferLength = expected data transfer length
dCSWDataResidue = hook to let device complain without failing when actual direction & length differ from expected
bCBWLUN & x0F = hook to add bits to the device addressing the bus supports natively
bCBWCBLength = hook to let people dispute how many bits of parameters the op can have
dCBWTag:dCSWTag = hook for running more than one command at a time, especially when we exploit bCBWLUN
dCBWSignature:dCSWSignature = hook to make room for the next standard
I'm guessing we can hope to achieve a reasonable quality of service if we provide only the first paragraph, though still we will pay for any part we choose to leave out. I imagine we could get away with shrinking dCSWDataResidue to one bit, i.e. zero or not. Arguably we could fold that into status, giving us pass without residue, pass with residue, fail with or without residue, and other.
Pat LaVarre
