As a variation on a theme, consider what the usb-storage driver does when its disconnect() routine is called. It does not abort the outstanding urbs, at least not directly. Instead, the disconnect() routine waits on a semaphore (which is held whenever the device is busy). Eventually, either:(1). The current transaction will complete ... or (2). If the device has physically disconnected, the ongoing transaction would never complete normally. ...I'd expect usb-storage should always hit case (1), given that case (2) is the "unlink urbs" case (excluding completions due to hardware faults).Not exactly. Case (1) is really logical disconnect (like rmmod) and case (2) is physical disconnect. Of course, a sane user will avoid
You described (1) as normal operation, (2) as scsi_eh kicking in. I should have disagreed with the (2) leading sentence that I quoted, or made my point by just quoting the later bit about scsi_eh. Most drivers (including usb-storage) _typically_ notice the errors due to the "device gone" hardware faults well before khubd wakes up and gets around to calling disconnect() ... or before the scsi_eh thread could kick in. (Hubs are supposed to poll about every 1/4 second, so typically drivers have lots of time to notice the faults first.)
The user might not know that's what's up, or might trip over a cable ...disconnecting a USB cable while the drive is actively executing a command, but then who says that all users are sane?
sanity isn't really the issue! :)
- Dave
-------------------------------------------------------
This SF.net email is sponsored by: Microsoft Visual Studio.NET comprehensive development tool, built to increase your productivity. Try a free online hosted session at:
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
