[371] in linux-scsi channel archive
Re: Reading more than buffersize
daemon@ATHENA.MIT.EDU (Drew Eckhardt)
Fri Jul 14 19:01:25 1995
To: "Eric Youngdale" <eric@aib.com>
cc: Christian Ullenboom <ulliull@uni-paderborn.de>,
linux-scsi@vger.rutgers.edu
In-reply-to: Your message of "Thu, 13 Jul 1995 21:50:27 EDT."
<9507132150.ZM400@aib.com>
Date: Fri, 14 Jul 1995 13:34:02 -0600
From: Drew Eckhardt <drew@poohsticks.org>
In message <9507132150.ZM400@aib.com>, eric@aib.com writes:
>>So how can I get more then 4000 byte with a single read-command without
>>patching the kernels buffersize. Scanning the whole page (8.5" x 14") at
>>300dpi with 255 colors would lead to 10Megs of data !!!
>
> I believe that the scsi-generics interface allows larger transfer
>sizes (up to 32Kb, if I am not mistaken. You will probably still get
>pauses in the output when you use this, but it may help.
>
> If you are ambitious, you try and come up with a driver that
>is a little more well-suited for scanners. I am thinking in terms of
>something that would allow for (and attempt to take advantage of) multiple
>outstanding commands. This would only work for drivers that are configured
>to allow for multiple outstanding commands, and multiple commands per lun,
>but in such cases you may be able to make the scanner "stream". I am
>thinking that the user program requests 10Mb of data or some such, and the
>scanner driver would break this up into a series of smaller I/O commands and
>attempt to overlap them as much as possible.
What really needs to happen is a change in the generic SCSI driver.
Instead of doing things to a buffer and then copying to memory, it should
lock the relevant pages of user memory in core (there are mlock patches
floating arround somewhere for this), and do however many SCSI commands are
necessary (based on the number of scatter/gather segments supported by the
low level driver being used) to transfer data to those locations.
