On Wed, 1 Jun 2005, James Bottomley wrote: > On Wed, 2005-06-01 at 14:45 -0400, Alan Stern wrote: > > Has there been any more progress on this issue? > > Well, the patch is in scsi-misc, if that's what you're asking. That's good. Is it too much to ask for an additional patch to zero out the sense data buffer after the error handler has finished with a command? After a transport error or a timeout there shouldn't be any sense data (races aside), but the error handler often leaves apparently valid data in the buffer, unrelated to the original command. By the way, is scsi-misc available anywhere as a patch (or set of patches) for those of us not on the bleeding edge, or does it exist only as a git repository? > > I spoke with Jörg Schilling (author of the cdrecord package, a widely-used > > sg client) and he said that failed operations should be retried > > automatically if the command had not gotten as far as being sent on the > > bus -- e.g., if the host adapter driver's queue was full. But if the > > command did get sent to the device then any subsequent failure should be > > reflected back to the client with no retrys. > > That's pretty much what we do now ... with the exception of QUEUE_FULL > and BUSY handling. What's the actual problem you were discussing? This isn't so much in response to a particular problem as it is an attempt to make the Linux sg driver more useful. (The discussion got started because of an actual problem, but that problem was at the USB level, not the SCSI level.) You may not have run across Schilling very much. He's done a lot of work on SCSI application programming on a variety of OS's. His opinion of the Linux SCSI stack isn't very high, although admittedly many of the problems he complains about only existed in much earlier versions of Linux. (Try reading through the some of the documentation or man pages for cdrecord and you'll see what I mean.) Anyway, he still talks about how Linux's sg interface is so much worse than Solaris's. Considering this issue of proper return codes and client control of the device, you can agree that he does have a point. He must think of himself purely as an applications programmer, not a kernel programmer, because he hasn't done anything to _fix_ these problems -- he prefers to complain about them. So I decided to see if something could be done to fix this particular issue, which does appear to be genuine. Overall, the motivation is simply to improve sg by making it more transparent, giving clients more control over the device, and returning valid and useful status. Alan Stern - : 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
