On Tue, 18 Mar 2003, Oliver Neukum wrote: > Am Dienstag, 18. März 2003 20:03 schrieb Alan Stern: > > I'm not convinced there will be so many bugs. usb_bulk_msg() and > > usb_control_msg() both can fail already, in several different ways with > > several different error codes. This would just add another failure mode, > > in which the error code happens to be -EINTR. But the drivers should > > treat it much like any other error. That is, unless they try to do some > > Nope, they must not. There are specific things to do in this case. > You have to determine the number of bytes already transfered and either > return that or EINTR.
It seems to me they have to do that already if an error is received from a synchronous call. But I haven't checked the source code for all the drivers to see whether this is really true. > So you have to fix every single call if you change > behaviour. And of course there could be very hard cases very transfers > have to be in specific order and simply aborting isn't an option. If aborting isn't an option, what does the driver do when it receives -EPROTO or -ENODEV? Alan Stern ------------------------------------------------------- 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
