On Sat, 2010-08-14 at 15:45 -0700, Matthew Dharm wrote: > On Sat, Aug 14, 2010 at 03:36:48PM -0700, Matthew Dharm wrote: > > That said, James has not yet addressed my point about allowing userspace > > tools to attempt the command, if they believe they can generate it. Nor > > has he addressed the history of this practice, whereby changing SCSI was > > the only way to prevent revisting the same fixes over and over again. > > Personally, I would also like to hear James' thoughts on future "cheap" > devices. > > Specifically, we constantly see more and more devices which only implement > enough functionality to respond properly to commands generate from Windows > or MacOS (and MacOS is a distant second). I'm not just talking about > command opcodes, but also parameters (i.e. max number of sectors to > transfer, mode pages supported, etc.) Well, we've parametrised a lot of this stuff already. There's (fortunately) only a finite number of ways manufacturers can screw up the mandatory initialisation sequences. > Generally, the only way to improve interoperability with these sorts of > devices is to make our stack operate more similarly to the "popular" OSes. > Many people have tried and failed over the years to get the device vendors > to change, and that's just not going to happen. I'm not really aware at the present time that there's a problem here. What we've already done seems to be working ... we should wait until trouble comes rather than borrowing it. > With more and more devices using SCSI (atapi, sata, usb MSC, sbp2, uas, etc.), SATA isn't SCSI its Serial ATA. There is a SATAPI which is Serial ATAPI (manly MMC and SSC over ATA over serial). UAS is the one I most fear in the above, but, as I said, since there's no current implementation, lets not borrow trouble. > it seems reasonable to me that we're going to see the same device-side > issues in one transport that we see in another. It is worth noting that > the sbp2 folks did gain from some of the changes we made for MSC, such as > the MODE_SENSE behavior. So, there is some history of success with this > approach. > > So, to me, it seems that we should be 'fixing' (and I use that term > loosely) these things in SCSI, which is common to all of those transports. Rather than being pejorative, why not just look at the potential fixes and see where they best fit? I grant that a spec failure in a mandatory command we don't currently parametrise will likely need fixing in SCSI. However, just a missing failure response to an optional command (a common firmware mistake) can easily be fixed in USB without troubling SCSI. James -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
