On Thursday 10 February 2005 9:36 am, Alan Stern wrote:
> On Thu, 10 Feb 2005, David Brownell wrote:
>
> > 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".
Make that "synchronous request timed out", and it'd be more accurate.
But I have a hard time agreeing, since UNIX (and hence POSIX and Linux)
has always conflated fault codes. It's unavoidable; even Linux only
defines about 130 of them, and there are a LOT more possible faults that
need to be indicated. Conflation is the only answer ... and I've seen
nothing to suggest that this particular one is troublesome. (If the
endpoint isn't responding, you'll get a synchronous request timeout
too...)
And FWIW the "official" definition of ETIMEDOUT is as a socket level
error indicating a connection timeout. That's a very close match to
"device not responding"; many HCD level error codes match socket codes.
While instead ETIME maps to "Timer expired" which is a better match
for what those synchronous requests are actually indicating. (Have
a peek at libc sysdeps/gnu/errlist.c ...)
> Do you know of any drivers that rely on ETIMEDOUT indicating "device not
> responding"? Especially considering that neither UHCI nor EHCI returns
> that code?
My friend Mr. GREP showed a bunch, and that's only for the in-tree drivers.
(I take it you didn't do that when you submitted that doc patch... even
within the directory with HCDs returning ETIMEDOUT.)
They've certainly had almost six years to notice that the documentation
says urb->status may return ETIMEDOUT, and that in fact it can do so.
Versus only a few months to notice that documentation-only change...
> 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?
"Better" has never been clear to me or I'd have changed something
myself. Changing fault handling logic is unfortunately error prone.
When POSIX started to change error code semantics to reduce the
overlap, it took many years for kernels and applications to adapt.
This seems like nice cleanup for a 2.7-on-the-way-to-2.8/3.0 kernel,
certainly, but otherwise it seems more like needless instability.
Do you not like ETIME? Or does that just beg too many questions
about whether the error isn't really in usb_{bulk,control}_msg()
for using ETIMEDOUT, when ETIME is a better match for what it's
indicating? No matter what such a change is, it's got to touch
a lot of fault handling logic.
- Dave
-------------------------------------------------------
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_ide95&alloc_id396&op=click
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
