On Thu, 10 Feb 2005, David Brownell wrote: > I don't like the idea of discarding fault details like that; they've been > too useful for tracking down the root causes of bugs. I also think that > EPROTO is way overused. How about ETIME, to avoid discarding the details? > > But just reverting that particular doc change would be simplest, since > this doesn't update the various drivers that know ETIMEDOUT gets returned > in various cases.
I still think it's a mistake to conflate "device not responding" with "request timed out". They really do indicate two very different sorts of errors -- as opposed to say "protocol error" and "invalid CRC", which are extremely similar sorts of errors. > In fact we should maybe use ETIME in usbcore not ETIMEDOUT (for the > request timer expiring). Likewise, ECANCELED rather than ECONNRESET > (for unlinking). Overall though, I don't much like changing the fault > behavior for existing calls; it's likely to add hard-to-find bugs. Do you know of any drivers that rely on ETIMEDOUT indicating "device not responding"? Especially considering that neither UHCI nor EHCI returns that code? But I bet there are drivers (maybe userspace drivers we're not even aware of!) that do use ETIMEDOUT to detect "no data available". So we'd be better off instead selecting a new error code for "device not responding", in the HCDs that can detect such a thing. How about ENOLINK, ENODATA, ECOMM, or ENOTCONN? Whatever gets used, drivers should treat it pretty much the same as EPROTO or EILSEQ. Alan Stern ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
