abel deuring <[email protected]> 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 <[email protected]> | 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
