This message is from the T13 list server.
Pat, I am game for certification and I am pushing it in OPEN SOURCE -- "end to end data integrity in filesystems" That is the goal. Regards, Andre Hedrick CEO/President, LAD Storage Consulting Group Linux ATA Development Linux Disk Certification Project On Fri, 7 Dec 2001, Pat LaVarre wrote: > This message is from the T13 list server. > > > > "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. > Subscribe/Unsubscribe instructions can be found at www.t13.org.
