Henning Meier-Geinitz wrote:
>
> Hi,
>
> On Sat, Nov 18, 2000 at 10:11:21PM +0100, Oliver Neukum wrote:
> > Hi,
> >
> > I'd like to ask whether that check
> >
> > if (real_buffersize != wanted_buffersize)
> > {
> > DBG(1, "sanei_scsi_open: could not allocate SG buffer memory "
> > "wanted: %i got: %i\n", wanted_buffersize, real_buffersize);
> > sanei_scsi_close(*fdp);
> > return SANE_STATUS_NO_MEM;
> > }
> >
> > in sanei_scsi.c might be removed. It makes using SANE with scsi drivers
> > which don't do scatter/gather very hard.
>
> I don't understand this fully. With sanei_scsi_open there is no way to
> tell the backend that the buffersize is smaller than expected. What
> happens if the backend sends a bigger buffer than allowed? Is it just
> slowed down or does the SCSI call return with an error?
> sanei_scsi_open already reduces the buffer size if
> proc/sys/kernel/sg-big-buff has a lower value but the backend can't
> find out about it if I understood correctly.
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)
This can have at least two nasty consequences:
1. A large buffer for the first open call, a small buffer for the second
open call: Assume that a backend sets up the read buffer size after the
first open call (eg, during sane_init), and that it stores the size of
this buffer in an internal variable. Then, the device file is closed and
opened again for a scan. This time, we get a smaller SG buffer size. If
the backend now tries to read more data then the changed value of
sanei_scsi_max_request_size allow, it is likely that the SG write/read
cycle will fail: If the SG driver was not able to allocate enough memory
during the open(2) call, it will probably not be able to allocate this
amount of memory a few seconds later.
2. A small buffer for the first open call, a large buffer for the second
open call: If the backend allocates a buffer of size
sanei_scsi_max_request_size after the first open, and tries to use
sanei_scsi_max_request_size in this buffer after the second open, it
will bail out with a segfault.
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.
> 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.
Exactly.
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 - 09:40:59 PST