On Sun, 2003-03-23 at 01:31, Matthew Dharm wrote: > The problem is this: usb-storage interfaces via SCSI, but not just for > disks. Tape, CD, etc. are all handled with the same protocol. Heck, ATAPI > disk/cd/tape are handled with these code paths.
ATAPI isn't really "emulated" in the sense that ATAPI devices understand a subset of SCSI commands (albeit according to their own rules). I'll give you the six byte mode sense, since ATAPI devices only do the ten byte version, but they nevertheless understand it. > > If there are known commands that devices have trouble with (whether > > emulated or not), maybe we could have helper routines to do some default > > filtering, and have the queuecommand function check those. But this just > > looks ugly and hacky to me. > > Well, there are lots of 'known commands' that fall in to this category. If > we had centralized helper functions, that would be great. But, as it > stands, right now all the low-level drivers have to do all that separately, > and badly. The problem with this type of approach is that there's no unified list of "known good" commands that actually let you operate a device. The SCSI and ATAPI standards have been gradually deprecating the commands that SCSI-1 (and sometimes even SCSI-2) regard as mandatory (READ_6/WRITE_6 springs to mind). Given this, the upper level drivers have to try playing a bit to see what the device will actually support. > Right now, we've got nothing, which leaves low-level driver folks out in > the cold. Well, for truly "emulated" (meaning the command is interpreted inside the driver and executed there instead of simply being repackaged and passed on to the device), a library of helper functions would be acceptable to place in the mid-layer if you want to write such a thing. > As I see it, SCSI commands break down into two basic categories: common > and uncommon. Common things (basic read and write, 36-byte INQUIRY, eject, > etc.) are all fine, but the 'uncommon' things (checking cache type, > 255-byte INQUIRY, etc) cause problems. I'm trying to find a way to choke > off the problematic commands without having to write code to recognize what > is being sent (and choke it off) based on what is in the command bytes. Under any definition of "common", a device that can't accept variable length inquiry commands is broken (by every known standard, even). However, lets not rehash old sore points. Could you elaborate on what the "problem" is. There seem to be two separate issues: 1. True devices which have incomplete state models for SCSI inside the real device and thus react badly to certain commands. For this one, I'm happy to have a helper library containing the elements of the SCSI state model for the devices to use, but I do believe that the drivers are broken and need fixing. 2. Certain real SCSI (or ATAPI) devices which have broken internal SCSI processing models. For these we need to not send certain commands which annoy them. This is much harder, since I don't believe we'll get a common definition of annoying commands that will work for every device. For ATAPI, we can probably get pretty far with a "no six byte commands" flag. This should be fairly easy to implement since every LLD tends to know when it is repackaging for an ATAPI device. What other rules would you need for this type of thing? James ------------------------------------------------------- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
