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
