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

[Julien BLACHE]

BERTRAND Joël <joel.bertrand at systella.fr> wrote:

Hi,

> I use a Snapscan 1236s with xsane on an i386 (K6-III/400, 256 MB,
> Adaptec 2940U, kernel 2.6.20.1) without any trouble. If I use the same
> scanner on an U2 (2xUltraSPARC-II/296 MHz, 2 GB, Happymeal-ESP, kernel
> 2.6.21-rc7), sane-find-scanner does not find any scanner but this
> scanner is shown in /proc/scsi/scsi. Both stations run lenny.

[Summary for sane-devel]
This is the old "Linux SG3 interface does not work in
32/64bit mixed environments". The most recent reference to this
problem I could find is the discussion that took place on sane-devel
(and some other lists at the same time) back in early 2003.


This bug made me dig a bit into this issue this afternoon; I don't
remember reading any of that yet, so here is what I found:

 - sanei_scsi doesn't work using the Linux SG3 interface in 32/64bit
   mixed environments
 - sg3-utils' sg_inq, which does something equivalent to what
   sane-find-scanner does, that is sending SCSI INQUIRY commands, does
   work

As it turns out, sanei_scsi uses the asynchronous SG3 interface (using
read/write calls on /dev/sgX), and sg3-utils now uses the SG_IO ioctl
interface.

The SG_IO ioctl benefits from the 32/64bit ioctl compatibility layer,
hence sg3-utils has no problems in a 32/64bit mixed environment.


So, in a nutshell, sanei_scsi needs to move to SG_IO instead of the
current interface if we want to support the more and more common mixed
environment case.


Attached is a proof of concept patch, tested on a Microtek scanner
(microtek2 backend); the scanner works like a charm with this code, it
feels like it even goes faster than using the async interface on the
same machine (with a 32bit kernel, last time I tried it took something
like 10 minutes to scan an A4 page with the default settings on an idle
machine, it's under 1 minute now).


I am not entirely sure that my patch behaves properly when an error
occurs; I don't know anything about sanei_scsi (well, didn't know
anything until today), so if someone familiar with sanei_scsi could
take a look, maybe we could fix this bug for good :-)

(note: with the SG_IO ioctl, we're loosing command queuing to the
scanner; doesn't look terribly important to me given how my test
turned out ...)


Bertrand, feel free to try this patch on your sparc64; as I said, it
works fine here (at least as long as nothing goes wrong ;), but better
keep your finger on the scanner's power button just in case. Tell us
how it goes.


That's a saturday afternoon well spent.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer - <jblache at 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 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sanei_scsi_SG_IO_ioctl.patch
Type: text/x-diff
Size: 4796 bytes
Desc: sanei_scsi PoC patch for SG_IO ioctl
Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20070428/f23c0321/sanei_scsi_SG_IO_ioctl.bin