I'm going to side with Justin and Dennis here.  I'd much rather get
called back with a length/phyaddr tuple and put it where I need.

int	bus_dmamap_load __P((bus_dma_tag_t tag, bus_dma_handle_t dmah,
	    caddr_t kva, size_t size, int flags));

One thing I don't like is that I when I start "loading", I don't
know how many segments I'll need.  There is also a variable amount
of S/G space left to fill.  Two, I don't want to have allocate a 
bus_dma_handle_t per mbuf.  It's much more logical for me to allocate
one per mbuf chain.  

The alternative is to allocate one (or two) per ring entry.  But when
you deal with 128 or 256 ring entries, that gets expensive.


If I had my choice, I'd like a finer grained approach.

	bus_dmamap_create -- unchanged.

	bus_dmamap_load __P((bus_dma_tag_t tag, bus_dma_handle_t dmah,
	    void *ctx,
	    int (*sg_load)(void *ctx, bus_dma_segment_t *sg),
	    caddr_t kva, size_t size, int flags));

	sg_load will return 0/error depending on if there was enough
	space on the device to use the segment.  If an error is returned
	that error will be the return value bus_dmamap_load.

	bus_dmamap_unload_segment(bus_dma_tag_t tag, bus_dma_handle_t dmah,
		bus_dma_segment_t *sg);

	returns the resources used by the above segment so that subsequent
	bus_dmamap_load can use them.  Note the following sequence needs to
	be allowed:

		bus_dmamap_load
		bus_dmamap_unload_segment
		bus_dmamap_load

	(ie. a partial deallocation and then reallocation).

	Note that the segments can be consumed and returned in any order.
	I don't want FIFO limitations.

I look at the bus abtraction like:

	bus_dma_tag_t			All the bus resources
	    bus_dma_handle_t		resources needed for <rx ring>
		bus_dma_transaction_t	resources needed for single rx
		    bus_dma_segment_t	single resource needed for a rx buffer

Right now, the transaction is missing.  That's what load and unload should
be acting on.


Lastly, bus_dnamem_alloc needs an alignment argument.  (the DEFxA needs
to allocate a 8K aligned piece of memory).

Hopefully, the above is somewhat comprehesable.
-- 
Matt Thomas               Internet:   matt@3am-software.com
3am Software Foundry      WWW URL:    http://www.3am-software.com/bio/matt.html
Westford, MA              Disclaimer: I disavow all knowledge of this message