[sane-devel] linux 2.4 scsi problems, sane 1.0.5

[Henning Meier-Geinitz]

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