On Tue, Aug 03, 2010 at 11:48:33AM -0500, James Bottomley wrote: > This is two devices, both identified by their usb (not SCSI) strings. > The problem is they crash rather than returning illegal command on two > specific SCSI commands. I don't see the problem in having the USB > command filter in usb_stor_control_thread returning this on their > behalf. SCSI will do the right thing and it's a lot less fragile. I'm willing to bet there are more devices out there like this. Experience has shown that the more we make the stack issue commands to the device like one of the "popular" OSes, the fewer problems we have. Thus, I prefer to fix these where commands originate. Also, every time I've tried to take the "filtering" approach in the past, I've been burned 6-10 months later by a change in the SCSI stack which brings these sorts of bugs back. I really prefer these things to stay fixed. You have to admit, there is something ill-conceived about a driver which is basically an HBA trying to second-guess code which actually generates the commands in the first place. If we can generate the command stream "better" (i.e. more compatible with a wider variety of devices), then everyone benefits. > It will also prevent the user space tools ... which no amount of SCSI > init changes can fix ... from crashing the devices. Granted, this is true. That said, user-space crashes have very rarely been an issue in the past. It does happen, but almost never due to this sort of thing -- in those cases, the device chokes on something relatively subtle about the command, which usb-storage would have a very very difficult time filtering on. Matt -- Matthew Dharm Home: mdharm-usb@xxxxxxxxxxxxxxxxxx Maintainer, Linux USB Mass Storage Driver DP: And judging from the scores, Stef has the sma... T: LET'S NOT GO THERE! -- Dust Puppy and Tanya User Friendly, 12/11/1997
Attachment:
pgpoFTM1MbMxL.pgp
Description: PGP signature
