On Friday 11 February 2005 7:39 am, Alan Stern wrote:
>
> How about this patch instead?
>
> Alan Stern
I like it much better. As doc, it might even still make 2.6.11 ... ;)
>
> = Documentation/usb/error-codes.txt 1.15 vs edited =
> --- 1.15/Documentation/usb/error-codes.txt2005-0
On Thu, 10 Feb 2005, David Brownell wrote:
> On Thursday 10 February 2005 12:08 pm, Alan Stern wrote:
> >
> > "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 f
On Thursday 10 February 2005 12:08 pm, Alan Stern wrote:
>
>"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 tim
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)
>
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 i
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 tha
On Thursday 10 February 2005 8:13 am, Alan Stern wrote:
> On Wed, 9 Feb 2005, David Brownell wrote:
>
> > > Do you mind using a different error
> > > code for no-response?
> >
> > I thought about it at one point, but didn't see a good choice about
> > what a better code would be. Got a suggest
