Re: reaction to a smaller buffer size

From: abel deuring (a.deuring@satzbau-gmbh.de)
Date: Sun Nov 19 2000 - 11:03:13 PST

  • Next message: Oliver Neukum: "Re: reaction to a smaller buffer size"

    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