Oliver Neukum wrote:
>
> > The problem is that a backend may consider sanei_scsi_max_request_size
> > as a constant. This was true for the old Linux SG driver; but with the
> > new SG driver it is at least in theory possible that you get different
> > buffer sizes each time a SG device file is opened. (Not very likely, but
> > it is possible)
>
> It's virtually certain if you have two host adapters, whose drivers differ
> in their ability to do scatter/gather. This means that SANE will always
> fail in that setup.
Oliver,
agreed, it is really not likely that we get different amount of memory
after different open calls. But exactly this can be a problem: Imagine a
Sane user working on an ooverloaded Linux box, who gets from time to
time segfaults, and that [s]he can't reproduce this behaviuor reliably.
How someone get the idea that this behaviour might be caused by a
changing sanei_scsi_max_request_size?
> > Both situations might have caused unnecessary work and headaches for
> > backend developers, who don't need or don't want to switch to
> > sanei_scsi_open_extended, and therefore I decided to use this "paranoid"
> > looking "if (real_buffersize != wanted_buffersize)", when I introduced
> > sane_scsi_open_extended and related stuff.
>
> I see, but in the case I mentioned above the user needs to limit the
> buffer by setting enviromental variables.
I remember. Another option would be to use the configure option
--enable-scsibuffersize. but of course this does not help either, if
someone is using a standard RPM.
>
> > > Why don't you use sanei_scsi_open_extended if it is available for your
> > > paltform? In this case the backend can try to get a big buffer and
> > > knows the actual size it is allowed to use.
>
> I am using an existing backend (microtek2). It works with this check removed.
> Is converting a backend to use sanei_scsi_open_extended difficult ?
The main task is to get rid of sanei_scsi_max_request_size; replace it
with something like s->maxbuffersize, and make sure that the backend is
really aware of a changing buffer size. When I changed the Sharp backend
to use sanei_scsi_open_extended, I replaced sanei_scsi_max_request_size
with xxxsanei_scsi_max_request_size, looked at every line causing a
compiler error, and checked, how sanei_scsi_max_request_size is/was
used: largest number of scan lines to be read with one SCSI command,
malloc() and so on. Next, you need to know, where close(devicefile) and
open(devicefile) are called, so that you can be sure that you won't have
close/open cycle e.g. between a malloc call and the usage of this
buffer.
For a test, you can deliberately change the buffer size for the open
call of consecutive scans.
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 : Sun Nov 19 2000 - 10:28:11 PST