Subject: Re: ahc and Semantics of the "COMPLETE" return code
To: None <gibbs@plutotech.com, mjacob@feral.com>
From: Matthew Jacob <mjacob@feral.com>
List: tech-kern
Date: 06/23/1997 22:35:04
>From gibbs@plutotech.com Mon Jun 23 21:57:17 1997
>>Unless, like NASA, you modify things to increase MAXPHYS to 1MB or better.
>
>In that case, I certainly hope that you are dealing with "mostly contiguous"
>buffers so that the target driver will always be able to service the request.
>The aic7xxx driver can transfer up to 16MB at a time if it doesn't run
>out of S/G segments.  The current FreeBSD driver has the number of segments
>reduced to 17 just to reduce the amount of wasted space taken up by the
>driver, and anyone who expects to be able to do larger transfers should
>be aware of this change.

No, we're cognizant of these issues- it's just that for some large
mass storage applications, transfers of < 1MB are uninteresting.

I should note that the Solaris/x86 AHC driver is also limited to 17
S/G limit- which makes for incompatibilities with tapes written under
Solaris/Sparc.

>
>Pluto made a few changes to physio to allow a user process to specify a
>physical address to a chunck of device memory and the I/O we do can
>also be quite large, but it's always to a contiguous piece of memory, so
>the S/G list length doesn't affect us.
>

Ah- that's nice- it'd be nice if a {read,write}{v} would just do the
right thing, though.