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.) 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. With more and more devices using SCSI (atapi, sata, usb MSC, sbp2, uas, etc.), 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. Matt -- Matthew Dharm Home: mdharm-usb@xxxxxxxxxxxxxxxxxx Maintainer, Linux USB Mass Storage Driver Sir, for the hundreth time, we do NOT carry 600-round boxes of belt-fed suction darts! -- Salesperson to Greg User Friendly, 12/30/1997
Attachment:
pgpFbw7ZHy3oj.pgp
Description: PGP signature
