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.
