Alan S: > > Meanwhile I will here now renew my solicitation of volunteers to help > > write a rationale for that .pdf that would make that .pdf less > > difficult to read accurately, and I thank you again for including me in > > this interesting thread. > > I volunteer to help.
Thank you! Yours is the first positive response since I began asking in 1998. I vote you launch a [usb-storage] storage suggesting a structure for us to fill out? Maybe you like copying the structure of the text as is? We could quote the spec line by line and insert discussion of what it really means, as I see you have done here, and I remember enjoying in the rational of the 1989 C standard. We could omit the uninteresting lines. That way, we can create an immediately useful but ever growing document. As each line comes into question, we'll add it. > Todd, the g_file_storage driver has an option that will cause it to make > the other choice. If you select the test version of the file-storage > gadget in your kernel's configuration, then you can specify as a module > parameter that it should not stall. You just say something like: > > modprobe g_file_storage file=... stall=n Ahh. Stall free BBB wins again. Wow. I remember me defending stall free BBB in committee against vehement opposition. I believe stall free BBB would not have survived except for me being cheerfully stubborn then. My employer had already shipped de facto standard in advance of the de jure standard, so I felt no great need for the de jure standard to publish quickly. Instead I wanted to build something that would last. I don't think I was smart enough to guess that devices would appear that could not precisely schedule STALL, even though already then we had a device that we were told could never STALL OUT. What we were told may have been translated to English from Hindustani or Taiwanese - the original limitation may have actually been that the device couldn't precisely schedule STALL OUT. I think I was just feeling that core USB saw STALL as an error, and therefore we should keep an escape in the BBB protocol that allowed talking entirely without error. For example, it has Always analogously bothered me that PC's choose to boot the HDD by deciding the FDD disk is absent. > > > a flaw in the Bulk-only protocol > > > > (: Mmmm, show me. :) > > Well, maybe not a flaw but a weak point. The spec offers the device a > seemingly valid choice that actually makes a demand the device may not be > able to satisfy. It would be better if the spec included some additional > language saying something like this: > > If the device is unable to guarantee that the Bulk-Out pipe > will STALL before all the data have been transferred, then it > must accept a total of dCBWDataTransferLength and not STALL > the pipe. Ah, flawed English, I agree, now I feel I understand, thank you. Pat LaVarre ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
