The same kind of thing holds true for khubd and enumeration. Any task doing a config change (like set_interface) should block signals, but otherwise I suspect all synchronous calls should be interruptible by default ... though someone ought to look for other cases where that's not true.
Should we simply add a flag to the synchronous calls or add interruptible versions?
Aren't those two options identical? Both are API syntax changes. :)
I agree with David's proposal above; just make usb_bulk_msg() and usb_control_msg() interruptible. But what about synchronous usb_unlink_urb()?
That wasn't exactly my proposal, for the reason Oliver mentioned: we'd destabilize drivers that don't behave as they "should".
Better to define a new call and selectively convert drivers to use it.
And implemenation-wise ... we can use the newish <linux/wait.h> macros "wait_event_interruptible", although that mis-accounts for tasks in "I/O wait".
- Dave
-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
