On Thu, 10 Feb 2005, David Brownell wrote:
> > 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...)
Certainly conflation is unavoidable. I wouldn't mind if "CRC error" and
"illegal bit sequence" were conflated, for example. They both indicate
low-level protocol errors, ones which (as far as I know) nobody needs to
tell apart.
The trick is to have conflation when it's not worth avoiding it, but to
keep separate the notions that really need to be separate. I think this
is such a case. "Device not responding" means either that the device
isn't working right or that it's disconnected from the bus (or there's a
lot of interference on the line, or a hardware fault...). It's a
low-level problem. "Request timed out" means that everything is working
correctly at the USB protocol level, and the device simply is unable to
send or receive data at the current time. It's a higher-level error.
> 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 ...)
You're correct. I wouldn't mind changing it the way you suggest, except
that it would involve changing a userspace/kernel API in a way that might
be important for some programs. Whereas using something other than
ETIMEDOUT for "no response" wouldn't be as big a change.
> > 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.)
Hold on there! I said "rely on". That means they won't work if some
other code is used for "no response". In fact there can't be any driver
like that, because neither UHCI nor EHCI uses ETIMEDOUT. If a driver did
rely on that code then it wouldn't work with those HCDs.
(And yes, I did use grep before submitting the doc patch. My mistake was
to search only in .c files, not in ohci.h. And the SL811 driver didn't
exist at the time, not in its current form.)
> 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...
The old documentation was confusing at best. As I recall, it said
ETIMEDOUT means something like "No ack, request timed out". The second
part is stating the obvious, and the first -- apart from being cryptically
brief -- leaves out the equally important requirement that a NAK isn't
received either.
> "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.
I'm willing to wait.
> 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.
I actually do like ETIME for "request timed out", reserving ETIMEDOUT for
"no response". I'm just concerned that it affects user programs as well
as the kernel. The message from Brian Murphy shows a good example.
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
