From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <06cb592e495ddaf9655a4d0ffae3c661@gmx.de> References: <06cb592e495ddaf9655a4d0ffae3c661@gmx.de> Date: Sun, 19 Jul 2009 17:21:16 +1000 Message-ID: <775b8d190907190021hadae3ffyea534970379e313d@mail.gmail.com> From: Bruce Ellis To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] new usb stack and implicit timeouts Topicbox-Message-UUID: 26f2ddc6-ead5-11e9-9d60-3106f5b1d025 The only justification I can see is to disconnect to stuff that's been unplugged or misbehaves. In your case that's not true. brucee On Sun, Jul 19, 2009 at 5:16 PM, wrote: > from the manpage: > > =A0 =A0 =A0 =A0 =A0For control, bulk, and isochronous transfers, there is= an > =A0 =A0 =A0 =A0 =A0implicit timeout performed by the kernel and it is not= nec- > =A0 =A0 =A0 =A0 =A0essary for applications to place their own timers. =A0= For > =A0 =A0 =A0 =A0 =A0interrupt transfers, the kernel will not time out any = opera- > =A0 =A0 =A0 =A0 =A0tion. > > souldnt the application / userspace driver know better than some > random choosen timeout in the kernel driver? > > also, this has not been taken into account for the new usb/ether. > > for now i'll just compare the errstr and try again, but this implicit > timeout stuff just smells "too smart" for me. > > -- > cinap > > >