Henning Meier-Geinitz wrote: > > Hi, > > On Sun, Oct 28, 2001 at 02:18:09PM +0100, abel deuring wrote: > > If my guess about Eric's problem is correct, I'll need to fix the Sharp > > backend -- but the question is, what to do with the result codes of > > sanei_scsi_req_wait and sanei_scsi_cmd[2]? A clean solution in the > > backend would be to retry a READ command, if sanei_scsi_req_wait returns > > SANE_STATUS_DEVICE_BUSY, and to return an error for > > SANE_STATUS_IO_ERROR. But at present, this would only work with the > > sanei_scsi.c parts for BSD_INTERFACE, FREEBSD_CAM_INTERFACE, > > SOLARIS_INTERFACE and SOLARIS_USCSI_INTERFACE, and (with a patch) for > > Linux. > > I think that's ok. Backends who want to catch BUSY can do so and the > others will fail as before. An alternative would be to resend the > command inside sanei_scsi but I don't know if this makes much sense.
Henning, Doing this inside sanei_scsi might cause quite a mess, if command queueing is used. Assume that the commands SET WINDOW and GET WINDOW are queued. The result of GET WINDOW depends on the execution of SET WINDOW, so re-issuing a failing SET WINDOW after GET WINDOW has been sent is simply confusing. The backends can better handle such a situation. > > > >From a more general viewpoint, I wonder, if we should specify the > > behaviour of sanei_scsi_req_enter, sanei_scsi_req_wait and > > sanei_scsi_cmd[2] more precisely. Another example is the timeout value > > for SCSI commands; for most OSes, this value is 1 minute, except for > > Linux, where it is 10 minutes (except for my mess with the SG3 interface > > in Sanei 1.0.3 and 1.0.4, where the timeout was only 10 seconds...) > > I think one minute should be enough but you never know... > > In my opinion, both items are for SANE 1.0.7, not for the upcoming > 1.0.6 release. I will add a TODO entry. Maybe someone can also look at > the Linux/sparc SCSI access problems mentioned in TODO. Or is this > already fixed? Right, that's all stuff for 1.0.7. ABel
