On Sat, 2009-02-28 at 16:19 +0100, Stefan Richter wrote: > Matthew Wilcox wrote: > > On Sat, Feb 28, 2009 at 03:53:31PM +0100, Stefan Richter wrote: > >> /Is/ the used transport protocol a good indicator for whether a > >> particular target breaks by READ CAPACITY 16? I have doubts. Command > >> set support is independent of transport protocol support. > > > > You must admit there's a striking correlation between USB devices and > > completely failing to follow the SCSI spec. Our current workaround of > > clamping USB devices at a SCSI_2 level does avoid much of the pain. > > OK, but currently implementations typically are: > 1. transport layer driver detects device with known flaws, switches on > a device quirk flag, > 2. transport layer enables quirk for all devices which it serves by, > default, possibly disables quirk for some whitelisted devices. > > Pulling the SCSI level down in usb-storage belongs into the latter category. > > Martin's proposal for transport identifiers includes the suggestion of a > third strategy: > 3. transport layer identifies itself, upper layer enable some quirks > based on that information (alone or in combination with whatever > other information). Actually, that's the piece of this proposal I'm explicitly saying no to: we're not going to code transport knowledge into the mid-layer because it's setting us up to get things wrong. The thing that may be useful in all of this is for udev to get the transport type from sysfs ... I'm not entirely sure about this one, since udev seems to do a pretty good job on its own without an exported identifier, but I can see an explicit one might be useful to it. > So, while it may be prudent to deduct "it's USB" -> "don't try READ > CAPACITY 16", why not keep implementing this in way #2? We will. That way if a wonderfully compliant USB device comes along (big if, I know) you can white list it in the USB (or SBP-2) layer and pass along its true SCSI compliance level. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
