This message is from the T13 list server.
I'm always in sympathy with people trying to make products that work in the real world. But if a lot of the issues you are seeing is ultimately traceable to folks just doing things like incorrect buffer allocations (i.e. asking for more data than they allocated space for), then I'm not very sympathetic. If you change standards to reward people with bad implementations, then you quickly end up with no one paying any attention at all to the standard (since they feel someone will bail them out). It's one thing to implement something with good faith and then find out there was a subtle interpretation issue that caught you. It's another to allocate C0 space and ask for FF in data back - that's just bad programming. Once again, in the case of 5 bytes for Inquiry, this should not be an issue if at least 6 bytes of data were allocated in the host buffer. In this case the extra byte is stored safely, and the host parses the allocation length to get the total return data size from the device. The host then re issues the Inquiry command again, and gets back all of the data (from byte 0) to put into the buffer. And I cannot imagine any recent (i.e. post 1995) software doing receive buffer allocations based on off byte sizes (I bet those FFh allocations all ma into 256 byte memory segments). Basically at some point very old and possibly incorrectly programmed software is not a major issue for the industry going forward. I'm not sure where to draw that line, but 1993 is pretty old for me (working in an industry that introduces a new product every 6 months). Jim PS this is not to say that there may not be a need for changes, just that this alone is not a very good reason in my opinion. -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Friday, December 07, 2001 12:28 PM To: [EMAIL PROTECTED] Subject: [t13] inaccurate residue explodes how - not enough buffer space 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. Subscribe/Unsubscribe instructions can be found at www.t13.org.
