Hi all,
Since I needed SCSI_IOCTL_SEND_COMMAND to work on linux-2.0.36, I have
made appropriate changes in scsi_ioctl.c to use the simple scattered
buffer handling I have proposed in my initial post.
For the fun, while applying changes to scsi_ioctl_send_command(), I
discovered no less that 5 trivial bugs in these 100 lines of code. AFAIR,
I heared that the required quality level for such category of code is
about 0.5 bugs for 1000 lines of code and I have been a lot impressed by
such a record of doing at least 100 times more bugs than expected. ;-)
Btw, I didn't fix all of them and perhaps added some in my patch.
This patch is not candidate for inclusion in the kernel, but people who
are currently working on the same problem may want to look into it.
Doing that and following my proposal, they would avoid being critisized
by me when they will made available their work. :-)
The patch can be downloaded from:
ftp://ftp.tux.org/pub/roudier/misc_stuff/scsi-scbuf-0.0-for-linux-2.0.36.patch.gz
Good luck!
I now go back to my todo list.
Regards,
G�rard.
On Sat, 20 Feb 1999, Gerard Roudier wrote:
> Hi all,
>
> Latest linux scsi subsystem still tries to allocate huge physically
> contiguous memory chunk. I know that large buffers are needed for devices
> as CD-R, scanners and friends, since Linus^Hx does not allow to DMA from
> userland. However, allocating large physically contiguous buffers should
> _never_ have been the solution, because it is only guaranteed to succeed
> at system start-up and it is wasting memory to pool huge buffers when they
> are not used.
>
> I have attached to this mail some _simple_ code that handles large buffers
> as a scatterlist and that, for now, is just tested against trivial bugs
> from userland. You may want to look into it and let me know if you think
> that it is worth to continue this work by making the sg driver, the mt
> driver and the SCSI_IOCTL_SEND_COMMAND rely on it.
>
> Basically, the needed big buffers could be allocated at open() or on the
> first IO after open() and freed on close(). For low-level drivers that
> handle large scatterlists, only 1 PAGE allocations will be performed at a
> time using the GFP_KERNEL priority that doesn't not require to be atomic.
> (and obviously outside the nasty io_request lock)
>
> The gain will be:
>
> 1 - guarantee to succeed for 'the 1 PAGE at a time' case, unless the
> kernel is completely screwed-up.
> 2 - no memory wasting since no big buffers are allocated for devices that
> are not open.
>
> Regards,
> G�rard.
>
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
