This message is from the T13 list server.
One definition of chaos is that the smallest imaginable changes in a conversation can amplify misunderstanding wildly ... > And is this 5 byte issue > one of the host > not having enough buffer space Sometimes yes. The generic flavour of UsbMass deprecates this case seemingly as Scsi-2 deprecates wide residue: a bridge has the OPTION of carefully passing back nothing more than precisely the number of bytes that direct-attached Pio would have read in. In the i/o layers of the o.s. familiar to me, the byte count that the host constructs for a command is the count of bytes that is supposedly allocated, thus a max count of bytes that may move, not necessarily the count of bytes that should move for the command. What's interesting is how much of the installed base we have a direct-attached legacy overestimates the count of bytes allocated. > (hard to believe they would not have > allocated at least 8 bytes anyway)? Summer 2001 I saw an app allocate xC0 bytes of space from a C stack, allocate other things next to that space, and issue a x 12 0 0 0 FF 0 command i.e. Inquiry for up-to-xFF bytes. This worked great for years with direct-attached Atapi for any device that didn't have more than xC0 bytes available. Then came a FireWire/Ata bridge (Ata, not Atapi) that made x90 bytes of Inquiry data available ... but also always wrote as many bytes as the Orb permitted. The app crashed indeterminately, because in effect the device had written more memory than the app owned. > ... I have reason to believe that the people who originally chose xC0 as an allocation length for the cb x 12 0 0 0 FF 0 were working in a Dos TSR that shared 640KiB with an app. I'm certain those people are now retired/dead. > ... What's fun about this case is that a bridge, such as a double-buffering host, can fix this case in general only if it can accurately discover how many bytes would have transferred in Pio mode. A double-buffering host can fix specifically this example if only it never passes back in more than xC0 - x90 = x30 unwillingly requested bytes that Pio would have avoided reading in. The byte counting inaccuracies of UDma, though growing, as yet appear well below that threshold for trouble. Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org.
