Re: [9fans] new usb stack and implicit timeouts

[Francisco J Ballesteros <nemo@lsub.org>]

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.