On Thu, 11 Jun 1998, Justin T. Gibbs wrote:

> >From the NetBSD source for x86:
> 
> typedef struct i386_bus_dmamap          *bus_dmamap_t;
> 
> struct i386_bus_dmamap {
>         /*
>          * PRIVATE MEMBERS: not for use my machine-independent code.
>          */ 
>         bus_size_t      _dm_size;       /* largest DMA transfer mappable */
>         int             _dm_segcnt;     /* number of segs this map can map */
>         bus_size_t      _dm_maxsegsz;   /* largest possible segment */
>         bus_size_t      _dm_boundary;   /* don't cross this */  
>         int             _dm_flags;      /* misc. flags */
> 
>         void            *_dm_cookie;    /* cookie for bus-specific functions */
> 
>         /*
>          * PUBLIC MEMBERS: these are used by machine-independent code.
>          */
>         bus_size_t      dm_mapsize;     /* size of the mapping */
>         int             dm_nsegs;       /* # valid segments in mapping */
>         bus_dma_segment_t dm_segs[1];   /* segments; variable length */
> };

Let me see if I understand the technical merits of this discussion.

W/ NetBSD, dm_segs gets allocated and initialized when the dma map is set
up. Under FreeBSD, a seperate structure is set up each transfer which
exists only for that transfer.  Since the NetBSD structure entry is
public, it has to always be there. 

As I understand it, NetBSD does this as a number of the things in the
dma_segments are "expensive" to set up, like cache entries, etc. It makes
no sense to create and destroy these "expensive" items. Also as I
understand it, for Wintel hardware, dma_segments end up being (little
other than) S/G lists. As I understand it, the FreeBSD change is to say
that the state represented by the dma_segments is not expensive at all,
and that the memory they'd require is. So let's not always have them lying
around wasting space.

Is this the general gist of it all?

If so, would a sutable compromise be to make dm_segs be private to the
implimentation, and bus_dma_segment_t *dm_segs[1]. For implimentations
where the state represented by dma segments is more "expensive" than the
memory they occupy, dm_segs points to a long-lived table of dma segments,
which is handed to the call-back routine. For implimentations where the
memory is more "expensive," the segment table is created on the fly?

I mean that it seems like the FreeBSD drivers won't care if the segment
table they are fed is temporary or long lived, so they won't need
changing. And the NetBSD implimentations which want this table to stick
around can have it.

Or did I miss something?

Thanks for listening.

Take care,

Bill