# Re: reaction to a smaller buffer size

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

- Next message: Henning Meier-Geinitz: "Re: Excessive Warnings from CVS build"
  - Previous message: Oliver Neukum: "Re: reaction to a smaller buffer size"
  - In reply to: Oliver Neukum: "Re: reaction to a smaller buffer size"
  - Next in thread: Oliver Neukum: "Re: reaction to a smaller buffer size"
  - Reply: Oliver Neukum: "Re: reaction to a smaller buffer size"
  - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  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

  - Next message: Henning Meier-Geinitz: "Re: Excessive Warnings from CVS build"
  - Previous message: Oliver Neukum: "Re: reaction to a smaller buffer size"
  - In reply to: Oliver Neukum: "Re: reaction to a smaller buffer size"
  - Next in thread: Oliver Neukum: "Re: reaction to a smaller buffer size"
  - Reply: Oliver Neukum: "Re: reaction to a smaller buffer size"
  - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  This archive was generated by hypermail 2b29 : Sun Nov 19 2000 - 10:28:11 PST