[sane-devel] [fujitsu] scsi-buf-size patch

[abel deuring]

Paul,

first a disclaimer: I'm not the maintainer of the Fujitsu backend, but I 
know a bit about sanei_scsi.c ;)

> The user should be able to work around this problem by setting the
> "scsi-buf-size" parameter in the fujitsu.conf configuration file to the
> total size of the image, and setting the SANE_SG_BUFFERSIZE environment
> variable to the same value.  However, a bug in sane-fujitsu currently
> prevents any SCSI buffer size setting larger than the default
> sanei_scsi_max_request_size from taking effect, and 
> sanei_scsi_max_request_size is often much smaller than what is necessary.

> --- sane-backends-1.0.14/backend/fujitsu.c	2004-03-04 13:09:56.000000000 -0700
> +++ sane-backends-1.0.14-patched/backend/fujitsu.c	2004-07-05 23:25:15.241452840 -0600
> @@ -501,20 +501,19 @@
>              {
>                int buf;
>                lp += 16;
>                lp = sanei_config_skip_whitespace (lp);
>                buf = atoi (lp);
> -              if ((buf >= 4096) && (buf <= sanei_scsi_max_request_size))
> +              if (buf >= 4096)

This patch works only with a bit of luck ;) The value of 
sanei_scsi_max_request_size tells the backend the maximum data block 
size that can be safely transferred with a single SCSI command. There 
are situations where this is also a hard limit. An example: Most ISA 
SCSI adapters can only transfer up to 64 kB with one SCSI command, due 
to limitations of ISA DMA architecture. (OK, anybody who is using a fast 
and relatively expensive Fujitsu scanner with cheap and old ISA SCSI 
adapter is probably a bit crazy, but it is possible to do that.) The 
SCSI subsystems of some operating systems supported by Sane may have 
some hard coded limits for the maximum data size of a single SCSI 
command, and this limit could well be as low as 64 kB or 128 kB.

The Linux SG driver is quite smart with its attempts to deal with huge 
data block sizes, so your patch may work in most cases for Linux, but it 
can also lead to situations where a scan may fail in a "mysterious" way. 
When an SG device file is opened, the SG driver allocates a data buffer 
for the SCSI commands, and the size of this buffer can be adjusted. If a 
SCSI command needs a larger buffer, the driver tries to allocate more 
memory for this single command, but if the machine is for some reason 
short on memory, the command will simply fail.

Generally, I'd recommend the following:

(1) replace the sanei_scsi_open calls with sanei_scsi_open_extended; the 
latter function allows to set the buffer size for each device file 
separately. This avoids the "bureaucracy" to deal with the 
SANE_SG_BUFFERSSIZE enviroment variable.
(2) If sanei_scsi_open_extended does not return the required buffer 
size, the backend should simply return an error by default. If some 
environment variable or some option in the configuration file is set, 
the backend may alternatively print a warning, via a DBG message. 
Additionally, the function do_scsi_cmd should also check, if the call of 
sanei_scsi_cmd failed with a SANE_STATUS_NO_MEM error, and if it failed 
it should print a warning, that the failure may be caused by a too large 
buffer size.

This way, users may try to perform a scan anyway, but in order to do 
that, they have to read some documentation, where they should also get 
an explanation that they must expect (perhaps random) scan errors, and 
that ignoring the maximum SCSI buffer size may not work on all platforms 
supported by Sane.

cheers
Abel