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. > >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? Bye, Henning
