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

[Julien BLACHE]

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.

> 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 ...)

JB.

-- 
 Julien BLACHE <jblache at debian.org>  |  Debian, because code matters more 
 Debian & GNU/Linux Developer        |       <http://www.debian.org>
 Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169