[ BTW, I'm trimming the CC list from now on; I know I'm tired of the
  duplicate messages, and I'm sure others are, too. ]

On Thu, 11 Jun 1998 20:03:25 -0700 (PDT) 
 "Dr. Bill Studenmund" <wrstuden@loki.stanford.edu> wrote:

 > 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?

For the record, that is already allowed in the NetBSD interface.  To
quote the manual page:

	The dm_segs member may be an array of segments or a pointer to an
	array of segments.  The dm_nsegs member indicates the number of
	segments in dm_segs.

It was specifically worded to allow the underlying implementation to 
allocate them on the fly if it desires.  The client merely needs to
make sure that it pays attention to dm_nsegs.  It doesn't matter to
the client since an array and a pointer to an array are accessed
the same way (i.e. foo[7]).

In other words, if it's _REALLY_ that important, it is possible to allocate
these things at load time, and free them at unload time (I really want
them to be accessible from the bus_dmamap_t, though, for devices where
this is important, and interface consistency when it's not).

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                            Home: +1 408 866 1912
NAS: M/S 258-5                                       Work: +1 650 604 0935
Moffett Field, CA 94035                             Pager: +1 650 428 6939