* [9fans] new usb stack and implicit timeouts @ 2009-07-19 7:16 cinap_lenrek 2009-07-19 7:21 ` Bruce Ellis 0 siblings, 1 reply; 23+ messages in thread From: cinap_lenrek @ 2009-07-19 7:16 UTC (permalink / raw) To: 9fans from the manpage: For control, bulk, and isochronous transfers, there is an implicit timeout performed by the kernel and it is not nec- essary for applications to place their own timers. For interrupt transfers, the kernel will not time out any opera- tion. 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] new usb stack and implicit timeouts 2009-07-19 7:16 [9fans] new usb stack and implicit timeouts cinap_lenrek @ 2009-07-19 7:21 ` Bruce Ellis 2009-07-19 7:54 ` cinap_lenrek 0 siblings, 1 reply; 23+ messages in thread From: Bruce Ellis @ 2009-07-19 7:21 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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, <cinap_lenrek@gmx.de> wrote: > from the manpage: > > For control, bulk, and isochronous transfers, there is an > implicit timeout performed by the kernel and it is not nec- > essary for applications to place their own timers. For > interrupt transfers, the kernel will not time out any opera- > tion. > > 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 > > > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] new usb stack and implicit timeouts 2009-07-19 7:21 ` Bruce Ellis @ 2009-07-19 7:54 ` cinap_lenrek 2009-07-19 9:07 ` Francisco J Ballesteros 0 siblings, 1 reply; 23+ messages in thread From: cinap_lenrek @ 2009-07-19 7:54 UTC (permalink / raw) To: 9fans [-- Attachment #1: Type: text/plain, Size: 379 bytes --] pulling the device gets me a "crc/timeout error", not a "request timed out". but i'm not sure if this is always the case though. the driver should not artificially generate errors in my opinion even if it would be convinient for some userspace drivers to have it. those who need a timeout should choose ther own value depending on what they are doing. -- cinap [-- Attachment #2: Type: message/rfc822, Size: 4032 bytes --] From: Bruce Ellis <bruce.ellis@gmail.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] new usb stack and implicit timeouts Date: Sun, 19 Jul 2009 17:21:16 +1000 Message-ID: <775b8d190907190021hadae3ffyea534970379e313d@mail.gmail.com> 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, <cinap_lenrek@gmx.de> wrote: > from the manpage: > > For control, bulk, and isochronous transfers, there is an > implicit timeout performed by the kernel and it is not nec- > essary for applications to place their own timers. For > interrupt transfers, the kernel will not time out any opera- > tion. > > 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 > > > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] new usb stack and implicit timeouts 2009-07-19 7:54 ` cinap_lenrek @ 2009-07-19 9:07 ` Francisco J Ballesteros 2009-07-19 11:05 ` Richard Miller 2009-07-19 11:41 ` Charles Forsyth 0 siblings, 2 replies; 23+ messages in thread From: Francisco J Ballesteros @ 2009-07-19 9:07 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs THere are some disks that do not respond to the controller after they crash. Also, RPCs carrying ctl requests to the devices may not respond either in some devices. I thought it was for sure an error when control and bulk requests took more than a while. Right now I´m not so sure regarding bulk transfers, but I still think it´s a good idea to timeout in the kernel control requests. pulling out is a different thing, as you say. ether requires more work, agree. On Sun, Jul 19, 2009 at 9:54 AM, <cinap_lenrek@gmx.de> wrote: > pulling the device gets me a "crc/timeout error", not a > "request timed out". > > but i'm not sure if this is always the case though. > > the driver should not artificially generate errors in > my opinion even if it would be convinient for some > userspace drivers to have it. those who need a timeout > should choose ther own value depending on what > they are doing. > > -- > cinap > > > > ---------- Forwarded message ---------- > From: Bruce Ellis <bruce.ellis@gmail.com> > To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> > Date: Sun, 19 Jul 2009 17:21:16 +1000 > Subject: Re: [9fans] new usb stack and implicit timeouts > 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, <cinap_lenrek@gmx.de> wrote: >> from the manpage: >> >> For control, bulk, and isochronous transfers, there is an >> implicit timeout performed by the kernel and it is not nec- >> essary for applications to place their own timers. For >> interrupt transfers, the kernel will not time out any opera- >> tion. >> >> 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 >> >> >> > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] new usb stack and implicit timeouts 2009-07-19 9:07 ` Francisco J Ballesteros @ 2009-07-19 11:05 ` Richard Miller 2009-07-19 11:30 ` Francisco J Ballesteros 2009-07-19 11:41 ` Charles Forsyth 1 sibling, 1 reply; 23+ messages in thread From: Richard Miller @ 2009-07-19 11:05 UTC (permalink / raw) To: 9fans > THere are some disks that do not respond > to the controller after they crash. Also, RPCs carrying ctl requests > to the devices > may not respond either in some devices. I thought it was for sure > an error when control and bulk requests took more than a while. Bulk pipes are not always used in a request-response manner -- they are just pipes. For many device classes (like ether or serial), a bulk read may need to wait an arbitrary amount of time until the other end has something to send. Have you seen anything in the USB spec which indicates a timeout for reading from a bulk pipe is appropriate? ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] new usb stack and implicit timeouts 2009-07-19 11:05 ` Richard Miller @ 2009-07-19 11:30 ` Francisco J Ballesteros 2009-07-19 11:51 ` Richard Miller 0 siblings, 1 reply; 23+ messages in thread From: Francisco J Ballesteros @ 2009-07-19 11:30 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > other end has something to send. Have you seen anything in the USB > spec which indicates a timeout for reading from a bulk pipe is > appropriate? > No. All devices I had tested at that time required a time out. Ethernet came later. I think it's better to remove the timeout from bulk endpoints (perhaps by making it optional) and leave it there in the case of control requests. I was just waiting to september, to give it time to the current code to show wichever bugs it may have. Perhaps is better not to wait. I strongly argue in favor of in-kernel ctl timeouts. Otherwise programs like usbd (and all drivers) will have a bad time. Moreover, I've seen devices that block on particular requests but crash if you interrupt them at bad times. The kernel is careful to interrupt the control transfers without bothering the device much. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] new usb stack and implicit timeouts 2009-07-19 11:30 ` Francisco J Ballesteros @ 2009-07-19 11:51 ` Richard Miller 2009-07-19 11:56 ` Francisco J Ballesteros 2009-07-19 13:40 ` erik quanstrom 0 siblings, 2 replies; 23+ messages in thread From: Richard Miller @ 2009-07-19 11:51 UTC (permalink / raw) To: 9fans > I think it's better to remove the timeout from bulk endpoints (perhaps by > making it optional) There's already a general way to time out any read/write operation alarm() and notify(). Why add a special case option for one particular type of file? I would say just remove it. > > I strongly argue in favor of in-kernel ctl timeouts. Yes, the control endpoint has a well-defined RPC protocol and lack of response is always an error. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] new usb stack and implicit timeouts 2009-07-19 11:51 ` Richard Miller @ 2009-07-19 11:56 ` Francisco J Ballesteros 2009-07-19 13:40 ` erik quanstrom 1 sibling, 0 replies; 23+ messages in thread From: Francisco J Ballesteros @ 2009-07-19 11:56 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > There's already a general way to time out any read/write operation > alarm() and notify(). Why add a special case option for one particular > type of file? I would say just remove it. > You're right. I'll do so. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] new usb stack and implicit timeouts 2009-07-19 11:51 ` Richard Miller 2009-07-19 11:56 ` Francisco J Ballesteros @ 2009-07-19 13:40 ` erik quanstrom 2009-07-19 13:53 ` erik quanstrom 2009-07-19 14:03 ` Richard Miller 1 sibling, 2 replies; 23+ messages in thread From: erik quanstrom @ 2009-07-19 13:40 UTC (permalink / raw) To: 9fans On Sun Jul 19 07:53:33 EDT 2009, 9fans@hamnavoe.com wrote: > > I think it's better to remove the timeout from bulk endpoints (perhaps by > > making it optional) > > There's already a general way to time out any read/write operation > alarm() and notify(). Why add a special case option for one particular > type of file? I would say just remove it. i'm confliced on this one. i want to agree with you, but have recient memory of uncooperative devices. and i would hate to limit the functionality of usb because we're trying to make things too simple. i'm not up-to-speed on usb. aren't there device types that take timeouts in their requests? isn't it easier to set up time timeout at the beginning? are there devices that if given a timeout will give their best available data when the timeout expires? sd doesn't deal with this problem. for example, currently most of the sd devices (orion is an exception) are uninterruptable. and you get whatever timeout you get. the sticky bit is that scsi and ata devices implement timeouts on the devices. these might not always be appropriate and you can't depend on anything. i have drives that vary from 53000s default timeouts to 2s default r/w timeouts. if you need a longer timeout than the disk or driver wants, you can't specify that with an alarm(2). and if you want a shorter one, aborting commands can take several seconds with sata devices. - erik ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] new usb stack and implicit timeouts 2009-07-19 13:40 ` erik quanstrom @ 2009-07-19 13:53 ` erik quanstrom 2009-07-19 14:03 ` Richard Miller 1 sibling, 0 replies; 23+ messages in thread From: erik quanstrom @ 2009-07-19 13:53 UTC (permalink / raw) To: 9fans > sd doesn't deal with this problem. for example, currently most > of the sd devices (orion is an exception) are uninterruptable. > and you get whatever timeout you get. > > the sticky bit is that scsi and ata devices implement timeouts > on the devices. these might not always be appropriate and > you can't depend on anything. i have drives that vary from > 53000s default timeouts to 2s default r/w timeouts. if you need > a longer timeout than the disk or driver wants, you can't > specify that with an alarm(2). and if you want a shorter one, > aborting commands can take several seconds with sata devices. sorry. that wasn't clear. i was talking about the raw file. - erik ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] new usb stack and implicit timeouts 2009-07-19 13:40 ` erik quanstrom 2009-07-19 13:53 ` erik quanstrom @ 2009-07-19 14:03 ` Richard Miller 2009-07-19 14:32 ` erik quanstrom 1 sibling, 1 reply; 23+ messages in thread From: Richard Miller @ 2009-07-19 14:03 UTC (permalink / raw) To: 9fans > aren't there device types > that take timeouts in their requests? There might be, but if so, that's the business of the device's own driver, not the usb driver. > isn't it easier to set > up time timeout at the beginning? Not if you use normal read/write to talk to usb endpoints (which seems to me a Good Thing). Normal read/write system call doesn't have a timeout argument. > are there devices that > if given a timeout will give their best available data when > the timeout expires? Again, if so, that's for the device's driver to set up and deal with, not the usb driver. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] new usb stack and implicit timeouts 2009-07-19 14:03 ` Richard Miller @ 2009-07-19 14:32 ` erik quanstrom 2009-07-19 15:14 ` Francisco J Ballesteros 2009-07-19 15:36 ` Richard Miller 0 siblings, 2 replies; 23+ messages in thread From: erik quanstrom @ 2009-07-19 14:32 UTC (permalink / raw) To: 9fans > > isn't it easier to set > > up time timeout at the beginning? > > Not if you use normal read/write to talk to usb endpoints (which > seems to me a Good Thing). Normal read/write system call doesn't > have a timeout argument. do you mean "normal read/write" vs. an rpc protocol, say, like /dev/sdXX/raw? - erik ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] new usb stack and implicit timeouts 2009-07-19 14:32 ` erik quanstrom @ 2009-07-19 15:14 ` Francisco J Ballesteros 2009-07-19 15:46 ` cinap_lenrek 2009-07-19 15:36 ` Richard Miller 1 sibling, 1 reply; 23+ messages in thread From: Francisco J Ballesteros @ 2009-07-19 15:14 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs that's what I understood. In any case I'll run the code through all devices I have before sending any usb patch. I'm still not sure that some disks currently working won't cease working if they do their own timeouts. I just want to be sure. I placed timeouts there only when I found uncooperative devices, in practice. In theory, not even ctl timeouts are needed. (I should get crc/timeout errors even in those cases according to the std). but I have learned the hard way not to trust any usb std. On Sun, Jul 19, 2009 at 4:32 PM, erik quanstrom<quanstro@quanstro.net> wrote: >> > isn't it easier to set >> > up time timeout at the beginning? >> >> Not if you use normal read/write to talk to usb endpoints (which >> seems to me a Good Thing). Normal read/write system call doesn't >> have a timeout argument. > > do you mean "normal read/write" vs. an rpc protocol, say, like > /dev/sdXX/raw? > > - erik > > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] new usb stack and implicit timeouts 2009-07-19 15:14 ` Francisco J Ballesteros @ 2009-07-19 15:46 ` cinap_lenrek 2009-07-19 15:58 ` Francisco J Ballesteros 0 siblings, 1 reply; 23+ messages in thread From: cinap_lenrek @ 2009-07-19 15:46 UTC (permalink / raw) To: 9fans [-- Attachment #1: Type: text/plain, Size: 74 bytes --] http://www.beyondlogic.org/usbnutshell/usb6.htm#SetupPacket -- cinap [-- Attachment #2: Type: message/rfc822, Size: 4208 bytes --] From: Francisco J Ballesteros <nemo@lsub.org> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] new usb stack and implicit timeouts Date: Sun, 19 Jul 2009 17:14:10 +0200 Message-ID: <8ccc8ba40907190814g652f88f6u817a3085b563fdf7@mail.gmail.com> that's what I understood. In any case I'll run the code through all devices I have before sending any usb patch. I'm still not sure that some disks currently working won't cease working if they do their own timeouts. I just want to be sure. I placed timeouts there only when I found uncooperative devices, in practice. In theory, not even ctl timeouts are needed. (I should get crc/timeout errors even in those cases according to the std). but I have learned the hard way not to trust any usb std. On Sun, Jul 19, 2009 at 4:32 PM, erik quanstrom<quanstro@quanstro.net> wrote: >> > isn't it easier to set >> > up time timeout at the beginning? >> >> Not if you use normal read/write to talk to usb endpoints (which >> seems to me a Good Thing). Normal read/write system call doesn't >> have a timeout argument. > > do you mean "normal read/write" vs. an rpc protocol, say, like > /dev/sdXX/raw? > > - erik > > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] new usb stack and implicit timeouts 2009-07-19 15:46 ` cinap_lenrek @ 2009-07-19 15:58 ` Francisco J Ballesteros 2009-07-20 7:12 ` Gorka Guardiola 0 siblings, 1 reply; 23+ messages in thread From: Francisco J Ballesteros @ 2009-07-19 15:58 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Sun, Jul 19, 2009 at 5:46 PM, <cinap_lenrek@gmx.de> wrote: > http://www.beyondlogic.org/usbnutshell/usb6.htm#SetupPacket > IIRC, I think the host controller is responsible for timing out requests sent to the device (I refer to setup packets), but my uchi does not. In any case, I don't think anyone wants to remove timeouts from ctl requests. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] new usb stack and implicit timeouts 2009-07-19 15:58 ` Francisco J Ballesteros @ 2009-07-20 7:12 ` Gorka Guardiola 2009-07-20 15:07 ` Dan Cross 2009-07-20 18:10 ` Lyndon Nerenberg 0 siblings, 2 replies; 23+ messages in thread From: Gorka Guardiola @ 2009-07-20 7:12 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Sun, Jul 19, 2009 at 5:58 PM, Francisco J Ballesteros<nemo@lsub.org> wrote: > On Sun, Jul 19, 2009 at 5:46 PM, <cinap_lenrek@gmx.de> wrote: >> http://www.beyondlogic.org/usbnutshell/usb6.htm#SetupPacket >> > > IIRC, I think the host controller is responsible for timing out > requests sent to the device (I refer to setup packets), but my uchi > does not. In any case, I don't think anyone wants to remove timeouts > from ctl requests. > > I am unsure I would remove timeouts even from bulk endpoints. It is true that some devices (the usb/serial for example) need to read for an undefined time waiting for data, but I don't think that is an issue as long as the timeouts are long enough, doing polling is quite easy. There is polling in the lower levels anyway. On the other hand, I think smart card readers go for lunch on a read and may never come back if there is no timeout. Of course alarm() can be used, but a timeout makes it simpler. I prefer having to poll on some cases than having to use signals on others. -- - curiosity sKilled the cat ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] new usb stack and implicit timeouts 2009-07-20 7:12 ` Gorka Guardiola @ 2009-07-20 15:07 ` Dan Cross 2009-07-20 16:25 ` Francisco J Ballesteros 2009-07-20 18:10 ` Lyndon Nerenberg 1 sibling, 1 reply; 23+ messages in thread From: Dan Cross @ 2009-07-20 15:07 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Pardon me if this is totally ignorant, but can't we just have a ctl message to control a timeout, which applications may then set on their own? On Mon, Jul 20, 2009 at 3:12 AM, Gorka Guardiola<paurea@gmail.com> wrote: > On Sun, Jul 19, 2009 at 5:58 PM, Francisco J Ballesteros<nemo@lsub.org> wrote: >> On Sun, Jul 19, 2009 at 5:46 PM, <cinap_lenrek@gmx.de> wrote: >>> http://www.beyondlogic.org/usbnutshell/usb6.htm#SetupPacket >>> >> >> IIRC, I think the host controller is responsible for timing out >> requests sent to the device (I refer to setup packets), but my uchi >> does not. In any case, I don't think anyone wants to remove timeouts >> from ctl requests. >> >> > > I am unsure I would remove timeouts even from bulk endpoints. > It is true that some devices (the usb/serial for example) need to > read for an undefined time waiting for data, but I don't think that is > an issue as long > as the timeouts are long enough, doing polling is quite easy. There is > polling in the > lower levels anyway. > > On the other hand, I think smart card readers go for > lunch on a read and may never come > back if there is no timeout. Of course alarm() can be used, but > a timeout makes it simpler. I prefer having to poll on some > cases than having to use signals on others. > > -- > - curiosity sKilled the cat > > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] new usb stack and implicit timeouts 2009-07-20 15:07 ` Dan Cross @ 2009-07-20 16:25 ` Francisco J Ballesteros 0 siblings, 0 replies; 23+ messages in thread From: Francisco J Ballesteros @ 2009-07-20 16:25 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs That is what I was considering instead of alarm-threadnotify (provided that the time out code in the kernel has to be kept there, for ctl transfers). But I'd like to provide the interface as it should be (otherewise there will be surprises). On Mon, Jul 20, 2009 at 5:07 PM, Dan Cross<crossd@gmail.com> wrote: > Pardon me if this is totally ignorant, but can't we just have a ctl > message to control a timeout, which applications may then set on their > own? > > On Mon, Jul 20, 2009 at 3:12 AM, Gorka Guardiola<paurea@gmail.com> wrote: >> On Sun, Jul 19, 2009 at 5:58 PM, Francisco J Ballesteros<nemo@lsub.org> wrote: >>> On Sun, Jul 19, 2009 at 5:46 PM, <cinap_lenrek@gmx.de> wrote: >>>> http://www.beyondlogic.org/usbnutshell/usb6.htm#SetupPacket >>>> >>> >>> IIRC, I think the host controller is responsible for timing out >>> requests sent to the device (I refer to setup packets), but my uchi >>> does not. In any case, I don't think anyone wants to remove timeouts >>> from ctl requests. >>> >>> >> >> I am unsure I would remove timeouts even from bulk endpoints. >> It is true that some devices (the usb/serial for example) need to >> read for an undefined time waiting for data, but I don't think that is >> an issue as long >> as the timeouts are long enough, doing polling is quite easy. There is >> polling in the >> lower levels anyway. >> >> On the other hand, I think smart card readers go for >> lunch on a read and may never come >> back if there is no timeout. Of course alarm() can be used, but >> a timeout makes it simpler. I prefer having to poll on some >> cases than having to use signals on others. >> >> -- >> - curiosity sKilled the cat >> >> > > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] new usb stack and implicit timeouts 2009-07-20 7:12 ` Gorka Guardiola 2009-07-20 15:07 ` Dan Cross @ 2009-07-20 18:10 ` Lyndon Nerenberg 2009-07-20 19:51 ` Dan Cross 1 sibling, 1 reply; 23+ messages in thread From: Lyndon Nerenberg @ 2009-07-20 18:10 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > I am unsure I would remove timeouts even from bulk endpoints. > It is true that some devices (the usb/serial for example) need to > read for an undefined time waiting for data, but I don't think that is > an issue as long > as the timeouts are long enough, Please show us the algorithm that *correctly* determines 'long enough' for every application talking to the devices. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] new usb stack and implicit timeouts 2009-07-20 18:10 ` Lyndon Nerenberg @ 2009-07-20 19:51 ` Dan Cross 2009-07-21 8:51 ` Francisco J Ballesteros 0 siblings, 1 reply; 23+ messages in thread From: Dan Cross @ 2009-07-20 19:51 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs fd = open("/some/ctl", OWRITE); write(fd, "timeout LONG_ENOUGH", length); close(fd); On Mon, Jul 20, 2009 at 2:10 PM, Lyndon Nerenberg<lyndon@orthanc.ca> wrote: >> I am unsure I would remove timeouts even from bulk endpoints. >> It is true that some devices (the usb/serial for example) need to >> read for an undefined time waiting for data, but I don't think that is >> an issue as long >> as the timeouts are long enough, > > Please show us the algorithm that *correctly* determines 'long enough' for > every application talking to the devices. > > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] new usb stack and implicit timeouts 2009-07-20 19:51 ` Dan Cross @ 2009-07-21 8:51 ` Francisco J Ballesteros 0 siblings, 0 replies; 23+ messages in thread From: Francisco J Ballesteros @ 2009-07-21 8:51 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs In the end, I'm going to let the user driver issue a timeout control request to devusb to activate timeouts if desired. Instead of forcing it to rely on alarm/threadnotify. The main reason is that the FS machinery used by some drivers may use different processes for different requests. Using notify would require installing handlers on them, but they are not `owned' by the driver. It's just that they call driver routines to implement read/write when the file belongs to the driver. Considering also that the tmout code in the kernel has to be there in any case to abort control requests cleanly, I think the easiest thing is to let the user activate this code for other types of endpoint (besides control ones). Perhaps I'm missing something. If anyone can see I'm making a mistake, I'd like to learn that. This is part of the interface for drivers and once we are happy with it it's likely to stay that way for a while. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] new usb stack and implicit timeouts 2009-07-19 14:32 ` erik quanstrom 2009-07-19 15:14 ` Francisco J Ballesteros @ 2009-07-19 15:36 ` Richard Miller 1 sibling, 0 replies; 23+ messages in thread From: Richard Miller @ 2009-07-19 15:36 UTC (permalink / raw) To: 9fans > Normal read/write system call doesn't >> have a timeout argument. > > do you mean "normal read/write" vs. an rpc protocol, say, like > /dev/sdXX/raw? No, I meant "normal read/write" vs more complicated things like select() in other operating systems. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] new usb stack and implicit timeouts 2009-07-19 9:07 ` Francisco J Ballesteros 2009-07-19 11:05 ` Richard Miller @ 2009-07-19 11:41 ` Charles Forsyth 1 sibling, 0 replies; 23+ messages in thread From: Charles Forsyth @ 2009-07-19 11:41 UTC (permalink / raw) To: 9fans disconnecting a usb device should result (eventually) in a suitable status on the relevant hub, and thus shouldn't require a timeout to get an error back to the user. devices that don't respond because they are in a bad state can be unplugged (if removeable). built-in devices on built-in hubs that get into a bad state probably need a usb or system reset, but some higher-level application (or human) timeout can interrupt a too-long delayed request. so far, i'd argue that a per-request timeout wasn't needed. ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2009-07-21 8:51 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-07-19 7:16 [9fans] new usb stack and implicit timeouts cinap_lenrek 2009-07-19 7:21 ` Bruce Ellis 2009-07-19 7:54 ` cinap_lenrek 2009-07-19 9:07 ` Francisco J Ballesteros 2009-07-19 11:05 ` Richard Miller 2009-07-19 11:30 ` Francisco J Ballesteros 2009-07-19 11:51 ` Richard Miller 2009-07-19 11:56 ` Francisco J Ballesteros 2009-07-19 13:40 ` erik quanstrom 2009-07-19 13:53 ` erik quanstrom 2009-07-19 14:03 ` Richard Miller 2009-07-19 14:32 ` erik quanstrom 2009-07-19 15:14 ` Francisco J Ballesteros 2009-07-19 15:46 ` cinap_lenrek 2009-07-19 15:58 ` Francisco J Ballesteros 2009-07-20 7:12 ` Gorka Guardiola 2009-07-20 15:07 ` Dan Cross 2009-07-20 16:25 ` Francisco J Ballesteros 2009-07-20 18:10 ` Lyndon Nerenberg 2009-07-20 19:51 ` Dan Cross 2009-07-21 8:51 ` Francisco J Ballesteros 2009-07-19 15:36 ` Richard Miller 2009-07-19 11:41 ` Charles Forsyth
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).