On Tue, Aug 03, 2010 at 10:14:48AM -0400, Alan Stern wrote: > On Mon, 2 Aug 2010, Hans de Goede wrote: > > > Hi, > > > > On 07/28/2010 03:19 PM, James Bottomley wrote: > > > On Fri, 2010-07-23 at 10:52 +0200, Hans de Goede wrote: > > >> Some USB devices emulate a usb-mass-storage attached (scsi) cdrom device, > > >> usually this fake cdrom contains the windows software for the device. > > >> While working on supporting Appotech ax3003 based photoframes, which do > > >> this I discovered that they will go of into lala land when ever they > > >> see a READ_DISC_INFO scsi command. > > >> > > >> Thus this patch adds a scsi_device flag (which can then be set by the > > >> usb-storage driver through an unsual-devs entry), to indicate this, and > > >> makes the sr driver honor this flag. > > >> > > >> I know this sucks, but as discussed on linux-scsi list there is no other > > >> way to make this device work properly. > > >> > > >> Looking at usb traces made under windows, windows never sends a > > >> READ_DISC_INFO during normal interactions with a usb cdrom device. So as > > >> this cdrom emulation thingie becomes more common we might see more of > > >> this problem. > > > > > > So, I suppose we can do this. I dislike threading device bugs like this > > > up and down the stack. The usb stor_control_thread already does some > > > command filtering; if it just rejected this command and READ > > > CAPACITY(16) on the flags, I think it would be far less code and the > > > SCSI subsystem would just do the right thing. > > > > > > I'd actually like to hear from USB what they'd prefer to do. > > > > > > > I was sort of hoping that Alan Stern would reply to this, but maybe he is > > on vacation? > > No, I'm here. I've been waiting to hear from Matt Dharm. He's the > usb-storage maintainer, so it's his call. Sorry, I've been travelling quite a lot lately. > In general it's hard to know how command filtering at the usb-storage > level will interact with the higher SCSI layers. In this case we have > James's assurance that it will be okay. usb-storage is really just a command/data transport mechanism. I've tried to keep the command filtering to an absolute minimum. In the past, we've engaged in command filtering and it was a pretty big disaster in terms of maintainance. Basically, my theory for pushing this into the SCSI layers comes down to these reasons: 1) A lot of these sorts of things only applies to one type of device or another. Either a specific type (CD-ROM, Random-Access, etc) or a specific vendor. It is much easier for SCSI layers to identify these devices than usb-storage to do so. In this specific case, we need to make a change only to how CD-ROM devices work; usb-storage doesn't track the device type. 2) A lot of these bugs will re-appear in either sbp2 or UAS, both of which use SCSI, so let's put all this in a common place rather than replicate it multiple times. 3) With many of these things, what we are really trying to do is implement some sort of sea-change in the command stream. Consider devices which only accept 6-byte commands instead of 10-byte commands. Usb-storage could intercept the 10-byte commands and either re-write all of them (problematic, we've tried this before) or reject them in such a way as to try to get the SCSI layers to generate the 6-byte variants (problematic, as the SCSI folks could change their logic at any time, we've tried this before). It makes *way* more sense to just *tell* the SCSI layers what we want, rather than do various forms of trickery to make it happen. In short, after years of running around trying to make devices work, the only reliable and maintainable way for doing this seems to be to make commands originate correctly, rather than try to intercept the commands in-flight and do some sort of fixup. Matt -- Matthew Dharm Home: mdharm-usb@xxxxxxxxxxxxxxxxxx Maintainer, Linux USB Mass Storage Driver P: Nine more messages in admin.policy. M: I know, I'm typing as fast as I can! -- Pitr and Mike User Friendly, 11/27/97
Attachment:
pgpflRtYmwzLT.pgp
Description: PGP signature
