[sane-devel] sane SCSI 32bit emulation on 64bit

[abel deuring]

Volker Kuhlmann wrote:
> Hello Henning,

>>Just to make one thing clear: Vuescan is NOT a SANE frontend. I.e. it
>>does not use any SANE backend. It's a completely independent program
>>with independent scanner drivers.
> 
>>It just happens to use a part of the internal low level SANE code
>>(sanei_scsi).

I don't want to open a discussion about licenses, but IMHO Sane's
exception to the GPL encourages cases like this one. I think it
would be more reasonable to put sane-backends under the LGPL, which
makes the rules for linking proprietary and free code very clear,
and especially enables end users to fiddle with the free code.
Exactly, what Volker would need here.

> 
> You're totally right, I should have made this clearer.
> 
>>Last time I looked at it (some years ago), this was done
>>without even adhering to the license.
> 
> Very noughty. You should really point this out to him.
> 
>>Abel posted a work-around for that.
> 
> Thanks much Henning!! I take it you're referring to this thread:
> http://lists.alioth.debian.org/pipermail/sane-devel/2003-January/006083.html
> 
> This is exactly what happens - the write() to the sg device returns
> EINVAL. The workaround of repacking the structure presents itself, I'll
> see if I can hack it (bad pun).

well, you'll need to find some way to map the values of 32 bit user
space pointers to 64 bit pointers (look for struct sg_io_hdr in the
kernel header file scsi/sg.h, fields dxferp, cmdp, sbp). That's
something the kernel (specifically, the SG driver in our case) can
easily do, but I am not aware of any way to do this inside an
application. The latter would require that a 64 bit kernel even has
something like a concept of 64 bit user space pointers for 32
applications. One way to go would be to patch the SG driver; the
other is to use the old SG interface, as I wrote in this mail:
http://lists.alioth.debian.org/pipermail/sane-devel/2006-January/015886.html

> Dieter, thanks for the thought - but it doesn't apply to vuescan, which
> is linked with sanei_scsi but doesn't use the sane backends.

No, Dieter is right indeed. Sane backends too use sanei_scsi.c. The
problems he had with his SCSI scanner under a 64 bit Linux Sparc
kernel boiled down exactly to the fact that you can't pass a 32 bit
sg_io_hdr structure to a 64 bit kernel.

It was also Dieter who tested #define DISABLE_LINUX_SG_IO .

Abel