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
