This message is from the T13 list server.
> [EMAIL PROTECTED] 12/10/01 21:40 PM > I am understanding better some of your messages Good to hear, sorry I come from such a different world. > In SCSI NON-DATA commands are not a problem. Agreed in Scsi and in Ide the device can signal clearly when it wishes to move no data whatsoever. Fun to count how many hosts don't see this an error. Let me accordingly polish what I said before: We can only say the receiver of Ide data clocks can't stop the transfer before R + X * 2 + 1 bytes have clocked across the bus if R is positive. In Scsi and Ide, the receiver of clocks always has the R = 0 option of deciding unambiguously to not move any data at all. > for DATA IN commands, > since the device terminates the command, > the lower levels > just assume > just assume > just assume Grin. > the lower levels just assume > that the device terminated it > by sending back the "correct" number of bytes > (as long as it is shorter than > that allocation length). > ... > all of that is the standard SCSI model. In practice, this varies by host. Some hosts are less reckless: they count bytes and complain if the byte count is wrong. Some of those hosts work only because they are less reckless: some kinds of trouble manifest themselves only as an unexpected variation in byte count. Do you mean to say less reckless hosts have departed from the standard SCSI model? Agreed, less reckless hosts depart from the de facto standard Wintel model. > for [each of the standard] > DATA OUT [commands] > the host always precisely > tells the device the transfer length > (number of bytes) it intends to transfer. Yes ... disagreements over byte counts appear only when the receiver cuts that expectation short. Like with a write error. I don't yet know that changig to report 3 * 512 + 4 of 7 * 512 bytes written rather than 3 * 512 bytes written will cause trouble ... but I'd rather not ship a million devices just to find out. Especially not if the fix for the data in that scares me more covers data out for me too. > Since 1993 I don't know > of any SCSI data being passed > that requires odd bytes (once again, > maybe some variable block size tapes ... No standard command, aye. As a maker of fully transparent bridges, I also care about the legacy of well-established vendor-specific practice that we have received from our forebearers. For example, when a password moves out, can it always move out together with enough pad bytes to round the total size up to a multiple of, say, x10? > It is up to higher level > software to take it from there. Higher level software can only work with the info the low level gives it. We can know that inaccurate byte counts are not helpful, no matter how unsure we are of precisely how harmful they are. Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org.
