Oliver Rauch wrote:
>
> Hi,
>
> there has changed a lot in the scsi buffer size handling in the past
> and I watched at it with one eye.
>
> Can someone tell me what must be done to implement it in a backend?
> Is it already really stable and will the interface keep the same in the future?
The simplest way to change the buffer size for existing backends, is to
set the environment variable SANE_SG_BUFFERSIZE. If an SG driver >= 2.0
is installed, sanei_scsi_open tries to allocate a buffer of the size
specified in that variable. Technically, sanei_scsi_max_request_size is
set to this value.
A problem with this approach is the following: Most backends open device
files in sane_init (or in a fucntion called from sane_init) to detect
the scanner model, and to set up the "usual internal stuff". Here, a
backend might allocate buffers, where the buffer size is based on the
value of sanei_scsi_max_request_size. Then, the device files are closed.
When a scan is started, the device file is opened again. This means,
that the SG driver needs again to allocate its internal buffer, and it
can happen, that it cannot allocate as much memory as requested.
Therefore, sanei_scsi_open will fail, if this happens. Otherwise,
sanei_scsi_max_request_size would not be constant during program run
time, and I was afraid, that this might crashes with some backends.
Practically, one should not choose too larger buffer sizes for the old
open call, since for larger buffers there increasing probability that
the SG driver cannot allocate the requested amount of memory.
Regarding switching to sanei_scsi_open_extended, the main task is to get
rid of sanei_scsi_max_request_size in the backend's sources, and to
replace it with the value returned in int *buffersize (the last argument
of sanei_scsi_open_extended). All mallocs and related stuff should be
based on the actual value of that variable. The practical aspects of
this work can be a little bit nasty: I was quite surprised when I
discovered, at how many occasions the Sharp backend used this variable,
and "cleaning" the backend from it took some time.
A more formal problem I saw in sanei_scsi.c, is the function
sanei_scsi_req_flush_all. This function "eats" _all_ queued SCSI
commands, without checking the destination device. Right now, this does
not hurt, but it would cause trouble for a frontend which is able to
operate more that one scanner simultaneously. (yes, that's a quite
theoretical question, but on the other hand, all backends seem to be
able to handle more than one scanner.)
Abel
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
This archive was generated by hypermail 2b29 : Sat Feb 05 2000 - 07:54:11 PST