# Re: scsi buffer size handling for backends

From: abel deuring (a.deuring@satzbau-gmbh.de)
Date: Sat Feb 05 2000 - 07:39:18 PST

- Next message: Bernd Schroeder: "Re: Failure to recognize Microtek ScanMaker V310"
  - Previous message: Yuri Dario: "Re: fork or pthread for async I/O?"
  - In reply to: Oliver Rauch: "scsi buffer size handling for backends"
  - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  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

  - Next message: Bernd Schroeder: "Re: Failure to recognize Microtek ScanMaker V310"
  - Previous message: Yuri Dario: "Re: fork or pthread for async I/O?"
  - In reply to: Oliver Rauch: "scsi buffer size handling for backends"
  - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  This archive was generated by hypermail 2b29 : Sat Feb 05 2000 - 07:54:11 PST