[sane-devel] sane SCSI 32bit emulation on 64bit
abel deuring
adeuring at gmx.net
Tue Jan 10 12:52:04 UTC 2006
Volker Kuhlmann wrote:
> On Tue 10 Jan 2006 06:58:20 NZDT +1300, abel deuring wrote:
>
>>http://lists.alioth.debian.org/pipermail/sane-devel/2006-January/015886.html
>
> Thanks for this link, my ISP routed that particular email to /dev/null.
>
>>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
>
> Ah, I was thinking it was solaris 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.
>
> Expanding the sg_io_hdr struct into 64 bit can be done by the
> application by copying members to a new memory area with 64 bit member
> alignment, and passing the new location to write(). As you say this
> doesn't extend the pointers from 32 bit into 64 bit pointer space, so it
> won't work. Darn.
>
> Patching the sg driver would only be for the dedicated user, if it's
> possible for the driver to autodetect whether the call was from a 32bit
> application.
>
>>It was also Dieter who tested #define DISABLE_LINUX_SG_IO .
>
> How much of a performance hit does this take?
A performance penalty should hardly be noticeable on a modern
system. The old interface worked fine even at a time of 100 MHz
processors. It mainly needs its own buffer malloced for the read and
write calls to the SCSI device. For the write call, the application
needs to memcpy the SCSI command data and the write data into this
buffer, for the read call, it needs to memcpy the SCSI read data
from the read() buffer into the the destination array provided by
the application.
The size of these read/write buffers depends on the backend; by
default sanei_scsi.c allows a maximum of 128 kB for the data; the
SCSI command and some additional data require a few dozen additional
bytes (I'm too lazy to look up the exact number right now).
Aside from the extra buffer, another drawback of the old interface
is that it simply concatenates the SCSI command data and the write
data, so that the SG driver must guess, where the SCSI command ends
and where the write data starts. This works fine in most cases, but
the guess goes wrong for one or two vendor specific commands used by
some Canon scanners. But sanei_scsi.c knows to handle this case.
Abel
More information about the sane-devel
mailing list