i wrote:

>Again, in my book, what you seem to mean by an "S/G list" is not a
>dmamap:
>
>  (i)  If it's in a device-dependent format, then it DOESN'T WORK.
>       (or, to be more precise, you incur the hair of a translation
>       function from DD to an MI format, which as you pointed out is
>       nasty; and on many (most?) NetBSD platforms, you save nothing,
>       since the bus layer has to build a NetBSD-style dmamap and stash 
>       it away for the duration of the transfer, regardless.
>
>  (ii) If it's not in a device-dependent format, but an MI format,
>       then I really, really really don't understand your claims to be
>       saving space by eliminating ``unecessary'' duplicated maps
>       (one in devive-dependent format, another in MI format).
>

Justin,

I'm sorry to keep harping on this point, but you keep using the term
"S/G list". I really dont think that's a good idea: it carries over
too much baggage from SCSI controllers.

On some machines, where DMA is non-cache-coherent, the hardware
_forces_ you to keep around a list of the physical buffer pages.
Your goal is to avoid actually building a dmamap for "simple"
implementations.

The way you do this is to postpone building the map until the driver
calls a callback.

But how is the bus-dma layer supposed to get at the map itself if the
only way to construct the map is ot call the _driver's_ callback?
This makes no sense to me at all. It's the same issue as with the 
outboard bus TLBs (mapping registers): if you need a virtual-to-physical
address map for every page in the DMA buffer, you need the dmamap;
and in your design, the bus layer itself cant' get at it.

I think it's entirely fair to claim that you roriginal claim is wrong:
there is a severe portability problem with the FreeBSD design in this
area.

I think we need to reach agreement on this point before any further
progress can be made; do you agree to the need to reach agreement?.



I'm thinking about adding a "BUS_DMAMAP_TRIVIAL" flag which lets a
driver and the bus_dma layer conspire to avoid constructing a map, if
and only if *both* the bus_dma layer and the driver dont need the map
info.  I think that's likely to be more successful than your approach.
Perhaps we could talk about that design approach?