>
>>In NetBSD, the dma map contains the S/G list of the mapping as well as
>>any implementation private data required to perform the mapping.  
>
>No, I don't think that's so. The bus layer gets to decide on the
>granularity of the dmamap, *not* the driver.  What to you looks like a
>signle "S/G list" entry could turn out to be multiple dmamap entries
>-- e.g., one for each physically-contiguous page, or some other
>granularity that's different from what the device thinks of as an s/g
>list.  (Of course, I could be mistaken, but that's the way i've been
>designing a busdma layer.)

>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 */
};

As you can see, the segment list is part of the bus dma map object.  On
other architectures, this data structure could contain other information
or "maps" of contained pages, but to the client that requested the 
bus_dmamap object to be created, they get a single object back.  In all
of my correspondence, I have been talking about the bus_dmamap object, not
"page maps" or other constructs the bus dma implementation may be using to
get it's job done.

>You keep talking about them both as s/g lists. I really cant tell if
>that's carelessness or if you truly dont appreciate the difference.

I'm talking about dm_segs which is an S/G list.

>>FreeBSD, the dma map contains only the implementation private data.  The
>>MI S/G list is provided only as an argument to the callback function during
>>a load operation.  The FreeBSD implementation completely separates the
>>S/G list from the dma map, so I don't understand your concern about a
>>mixture of the two terms or what they mean.
>
>Justin, until you stop referring to dmamaps as "s/g" lists, I can't be
>sure we are really talking about the same thing.  for a technical
>discussion, that's almost always fatal.

Again, I am talking about dm_segs and the bus_dmamap object.  Perhaps you
are not familiar with the contents of arch/include/bus.h on any NetBSD
platforms?  That could certainly cause a terminology problem.

--
Justin