[sane-devel] [RFC, PATCH] Re: Bug#420193: libsane on sparc64 with SCSI scanner

[abel deuring]

Hi Julien

Julien BLACHE schrieb:
> abel deuring <adeuring at gmx.net> wrote:
> 
> Hi,
> 
>> are you sure that the 32/64 bit problem is _not_ fixed for the
>> read/write interface, but only for the ioctl? If so, we should indeed
> 
> Yes; I've read the code in sg.c and in the ioctl compat layer, and
> sg.c doesn't do anything to fixup the 32/64bit issue.
> 
>> use the ioctl call in sanei_scsi. But if we do so, we should at the same
>> time get rid of all the queue management. If you compare the Linux part
>> of sanei_scsi with that for other operation systems, you will note that
>> the code is much simpler, mostly due to the fact that these OSes all use
> 
> Ohhh yes... that would greatly simplify sanei_scsi. It's been fun to
> workaround the async code to get the ioctl in sanei_scsi :]

;)

>> a simple ioctl instead of the write/read logic. OK, this would also mean
>> to change a bit more in sanei_scsi, especially it would mean that the
>> check for the availability of the SG_IO ioctl would be moved from run
>> time to compile time.
> 
> I think we can even get rid of the old SG interface entirely. SG_IO
> exists in Linux 2.4 too, so it should be safe.

I must admit that I am one of these persons who cannot throw away
anything... But you are right: Doug Gilbert wrote the SG3 interface in
the late 90ies (IIRC, the first versions were available even for 2.2.x
kernels), so keeping the old interface would be useful for very few
people, if any.

>> But I am quite surprised that your Microtek scanner is so much faster
>> with the ioctl is than the current implementation. When Doug Gilbert had
> 
> It can be due to changes in the microtek2 backend too. Honestly, I
> haven't bothered to check :)
> 
>> implemented command queuing for the SG driver, I noticed a considerable
>> performance gain for the Sharp JX250 scanner. The latency between the
>> end of a SCSI command and the start of the next command (from the
>> viewpoint of the scanner) is lower, if the command has already been
>> issued by the application, so the kernel can start the next command
>> immediately, without a context switch to the application. On the other
>> hand, this was at a time, when processors had clock speeds of 200 or 300
>> MHz. With modern processors, the latency is small enough even if "kernel
>> level queueing" is not used.
> 
> The latency here seems low enough, and this machine is an SGI Indigo2
> R4400SC 200 MHz w/256 MB RAM and an asthmatic SCSI controller (under
> Linux, at least, because we don't have the specs ...)

The effects of longer latency times seem to depend heavily on the
scanner models. The Sharp JX250, a moderately fast model, probably with
only a tiny internal buffer, seems to suffer more than many other devices...

Abel