[sane-devel] Current TODO list

[abel deuring]

Henning Meier-Geinitz wrote:
> 
> Hi,
> 
> On Sun, Jan 20, 2002 at 12:47:45PM +0100, abel deuring wrote:
> > Henning Meier-Geinitz wrote:
> >
> > > sanei
> > > -----
> > >   * sanei_scsi: Check return values of req_wait and cmd in case of
> > >     SCSI DEVICE BUSY. Better specification of the behaviour of sanei_scsi
> > >     functions (e.g. return values, timeout 10 min versus 1 min)?
> >
> > what do you mean with "check return values"?
> 
> I think I was referring to your mails on sane-devel on 2001-10-28: "Re:
> [sane-devel] linux 2.4 scsi problems, sane 1.0.5". If I summarized it badly or
> it's outdated just say it.

Seems that I need a memory upgrade ;) 

Thinking again about the DEVICE BUSY stuff, I have doubts, if it is
worth the effort to specify the behaviour, how to map SCSI status code
to enum SANE_Status more precisely -- and especially to implement this
common behaviour with the current functions sanei_scsi_req_enter /
sanei_scsi_req_wait / sanei_scsi_cmd. The behaviour of these functions
should of course be as unique as possible for all the operation system
supported by Sane, but we should perhaps take a different approach.

Firstly, I don't see the point, why sanei_scsi should hide the SCSI
status code from the backends. After all, the backends must eventually
deal with many SCSI errors, and the SCSI reference manuals for most
scanners describe more or less detailed, how to interpret the status
code for each command. 

Secondly, there are a few other issues with sanei_scsi.c: a)
sanei_scsi_req_enter and sanei_scsi_cmd have only one parameter for both
the CDB and for write data. While this is fixed with
sanei_scsi_req_enter2 / sanei_scsi_cmd2, these functions also do not
have the most clever parameters: you can specify read _and_ write data
for a command, which is not possible for SCSI command, AFAIK. (Ok, it
was myself, who wrote these functions: My problem was that I dared to
change the implementation for quite a number of operating systems that I
don't have available; so I tried to keep the changes to a minimum.) b)
Most backends use the global variable sanei_scsi_max_req_size to get the
max size for SCSI data blocks. This requires to set
sanei_scsi_max_req_size to a value supported by all drivers/adapters.
So, if both an ISA adapter allowing on 32 kB data blocks and a modern
PCI adapter are installed on a machine, the scanner connected to the PCI
adapter might be slowed down.

Considering all this, it might be better to define and implement a new
interface for sanei_scsi, which avoids these problems, and to write
wrapper functions for the current interface. This would result too in a
"more common" behaviour of the current interface across different
platforms, while the backend authors have also the choice to use a
cleaner interface. 

> 
> > Regarding the timeout, I think we should switch a common value of 1
> > minute. I assume that most development is done under Linux, where we
> > have a 10 minute time out at present; the 1 minute timeout for other
> > operating systems might cause unexpected errors if a backend for a
> > really slow scanner is developed under Linux.
> 
> 1 minute should be ok even for the slow Mustek scanners :-)

ok, I'll change that.

Abel