My main problem with this proposal is that it doubles the space required
for sg entries and forces a copy of the bus_dma_segment_t information into
the private format of the driver.  This seems an enormous penalty
especially when you start thinking about devices that handle a large number
of segs (the aic7xxx cards can have up to 2k of SG space per SCB which is
perfect for writing those large LFS segments) and the fact that the full
format of the bus_dma_segment_t type is opaque so the copy cannot happen
efficiently (memcopy) even if the two top members of the bus_dma_segment_t
correspond directly to the private driver format.  I would much rather see
a family of functions that handle different sg formats which allows the
code to be shared among drivers (e.g. the ahb, bt, and aic7xxx, with the
exception of length of list have the same format) and kept in one place so
that they are easy to port among archs and update if the API changes.
This removes the need for translation code in each driver and no extra
mapping space is needed.

If you don't have a family of functions, the interface has to be enhanced
to deal with the restrictions of the different SG formats.  I don't see
a per SG size limit in the API and this varies from device to device.

I would also like to see the interface deal with DMA transactions that span
multiple contiguous KVAs (aka buffers).  I should be able to read tapes
from an SGI that use a 256k block size even if my tape drive is hanging
of an old 1542(16 SG segments).  Heck, I should be able to read tapes
written on a NetBSD system with a 256k block size too. I don't see any
of this happening unless we can circumvent the MAXBSIZE/MAXPHYS limits
by spanning buffers in a single I/O transaction.

--
Justin T. Gibbs
===========================================
  FreeBSD: Turning PCs into workstations
===========================================