This message is from the T13 list server.
Send to reply time just kicked up from one minute to two hours. My apologies in advance to anyone who sees this twice. >>> Pat LaVarre 12/07/01 04:23PM >>> > "Mcgrath, Jim" <[EMAIL PROTECTED]> 12/06/01 05:52PM I hope it's clear I appreciate this exchange. Makes me think, still now, even after I've been persuaded away from my glaringly wrong opinions of a week or so ago. > How to Handle Bad Implementations > > ... the better approach here is to > focus on compliance testing and certification I have some small hope of seeing an open source movement get going to make compliance testing concrete & meaningful, rather than pr*prietary & silly like so much of it is now. Would be way way way cool if someone back here in work-for-money land figured out how to fund such an effort. The UsbMass hall of distinctive fame/shame is: <http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/linux-usb/storage/unusual_devs.h?rev=1.20&content-type=text/vnd.viewcvs-markup> now at Revision 1.20 , Sun Sep 2 05:12:57 2001 UTC. There we see celebrated in detail the unusual UsbMass creativity of ATI, Belkin, Casio, Datafab, Frontier Labs, Freecom, Fujifilm, Hagiwara, Hitachi, HP, In-System, LaCie, Lexar, Matshita, Microtech, Minds@Work, Mitsumi, Olympus, Sandisk, SCM Microsystems, Shuttle, Sony, and Y-E Data. A number of the vendors celebrated here appear because they made the conservative choice of NOT claiming to comply with the UsbMass specifications ... but their stuff seems to work mostly anyhow. We have to turn to the USB_FL_ flags to see who have been judged to benefit from host-side extensions to the UsbMass standards i.e. Belkin, Casio, Datafab, Frontier Labs, Fujifilm, Hitachi, Lexar, Minds@Work, Mitsumi, Microtech, Olympus, Sandisk, SCM Microsystems, Shuttle, Sony, Y-E Data. Extensions aren't necessarily bugs. I think I remember US_FL_SCM_MULT_TARG steals a reserved field (maybe an obsolete field?) to convey a specific Scsi ID apart from the dCBWLUN. I think I remember US_FL_INQUIRY is for people who got op x12 Inquiry wrong. Yes, people get Inquiry wrong. HOW can ANYONE get INQUIRY wrong. There is no simpler command ... ... please excuse my outburst, we now return to your regularly scheduled program ... I think I remember US_FL_MODE_XLATE is for people who implemented Wintel Scsi rather than Scsi by way of supporting the optional x5A/55 Mode Sense/Select (10) in place of the required x1A/15 Mode Sense/Select (6). > The UsbMass hall of distinctive fame/shame Hasn't discouraged people from non-compliance, as far as I know. > How to Handle Bad Implementations > > ... the better approach here is to > focus on compliance testing and certification Can we effectively promote compliance testing? Clearly, conceptually, compliance testing could amplify the competitive advantage we get from making stuff that just plain works. But who really cares about third party testing and certification? For example, acquiring the DesignedForWindows logo is such a slow and expensive and silly process that people leave it off of retail products. Who but OEMs require it? So often single-party testing and certification is silly - maybe that is the nature of something that is s*cret and pr*prietary: we're all left at the mercy of the least amazingly competent programmer in the test house. Time and again I've changed designs to fake out some test that was testing something unreal. Is this not a common experience? > Bad implementations will always be with us. > If you need to design something that can work > "in the real world," > > .. compliance testing and certification > ... will not eliminate bad implementations, > but will allow you to label a lot of them as such > and thus have a legitimate reason to ignore them in your design. Yes exactly. The stuff I sell is useless in isolation. It functions only as part of a chain of connections from the gui of the user out to the magnetic particles of the media. The cool thing about a fully transparent Abc/Xyz bridge is that the bridge designer can say that either the Abc host or the Xyz device can fix whatever problem arises. In my world, whoever fixes a problem walks away tarred with some blame for not having fixed the problem before it arose. By making a bridge fully transparent, we make all problems appear to belong to the Abc host or the Xyz device. Good politics. Are people not the same where you live? > "in the real world," > then you really do need a uP based implementation > with a lot of smart code > to handle a lot of different screwy implementations. Yes. The question for a bridge of Xyz/Abc is do you need a third uP in the bridge. Maybe the uP in Abc and/or the uP in Xyz can cover the issue. > "in the real world," > then you really do need a uP based implementation > > If you were selecting all parts yourself, > then in theory you could avoid this. For our flagship volume stuff, we do select bridge and device together. For other devices, compatibility thru the bridge becomes a procurement criterion. If the Atapi device doesn't implement enough of Scsi to function directly as a UsbMass device, it changes. We bludgeon the Atapi programmer with the club of the seductively low cost of the fully transparent Usb/Atapi bridge. > But even then unanticipated bugs > and future (needed) enhancements > make a flexible design so much better. Doesn't anyone in your shop suffer from feature-itis? Masking the rom empowers the programmer to say no thank you, to the perennial requests for silly new features. > I hope it's clear I'm enjoying this exchange. To celebrate a particular example ... til I was provoked here to answer, I did not appreciate that ... Delaying clocks sent at negotiated block size boundaries for a turnaround or more suffices to reduce the inaccuracy in apparent Dma residue to zero, provided the block size is even. I'm really curious now to know if this is how Ata devices avoid trouble in the real world. Pat LaVarre P.S. In my judgement, the text below is free of the NDA that regrettably hides away most usb-mass traffic from the world at large: > (usb-mass 77) Re: link to [Linux] Usb Mass CVS? >... 11/19/01 06:45PM >>> Just to make things clear to people.... the stuff Pat is pointing to is the CVS repository used by the Linux USB Mass Storage team ... The unusual_devs.h file gives a good indication of how much pain [we've] had in trying to write a driver to support as much different target hardware as possible. It's just a list which allows the driver to identify certain devices and invoke special code paths (or completely different ones!) for those devices. Most of the rest of the code is the driver itself. Look for tests on US_FL_* defines to identify where items are special-cased. These are the behavior-changing flags... tho, those don't cover the devices in the unusual device list which are getting their SubClass or Protocol overriden. You also need to understand that, like all the other OSes I know, Linux implements USB Mass Storage as a virtual SCSI adaptor. So what's being fed into the queuecommand() function are a linux-internal representation of a SCSI command, including CDB, buffer pointers, etc. ... Subscribe/Unsubscribe instructions can be found at www.t13.org.
