> The architectural compromise is machine-dependent modules for
> device-dependent scatter/gather list formats.  Given that you need to
> have device-, bus-, and machine-independent DMA mapping anyway, your
> suggestion actually adds more code.

In fact I don't think this is true.  All you strictly need is two
types of DMA mappings, a device-dependent one which represents the
scatter-gather list to be given to the hardware, and a bus-dependent
one which records the bus resources allocated for the transfer so
they can be deallocated afterwards.  The machine-independent mapping
is something additional and extraneous, that you've invented as a
parameter-passing mechanism between the bus code and the device code
which constructs the device-dependent state.  Since you've essentially
embedded the machine-independent map in storage allocated for the
bus-dependent structures (whatever they may be) it doesn't cost much
in the case when there is bus-dependent state you need to track, it
just increases the size of the structure a bit.

What I think Justin is complaining about is that the machine-independent
format used for parameter passing becomes "much more" expensive (relatively)
for buses which would otherwise require no bus-dependent state be kept
at all, as it requires you to allocate something when you could get
by with nothing (since allocating something is always many times more
expensive than allocating nothing).  Since buses which require no
bus-dependent mapping state are quite common, this does cost.

Given that the machine-independent state is only needed for parameter
passing, it seems to me that that there are other possibilities which
eliminate the machine-independent state altogether.  For example,
in bus_dmamap_load() allow the driver to specify two additional
arguments, an opague buffer into which the driver-dependent data
will be formatted and a procedure handle (into the driver code)
which is called with each address/length generated by the s/g code.
Then bus_dma_handle_t can become entirely opague to driver code, and
in fact need not point to anything for buses which need to carry no
state (e.g. for PCI on a PC all entries except bus_dmamap_load() can
be NOPs).  It adds no code, since the driver will need to know how
to generate and store device-dependent s/g lists in any case, it just
avoids all the allocate-and-free junk for buses which wouldn't otherwise
have to allocate-and-free anything.

Or something.

Dennis Ferguson