I'd like to emphasise, up front, that I'm trying hard to understand
the technical issues which Justin is making a case.  I admit freely
that I'm struggling, that a number of points have me very confused.

Justin, where I'm at right now is I dont see how I could make your
reworked bus-dma API work well on a number of machines.  You've said
there are no portability problems, I've said where I see some.

'm afraid I still don't see how it'd work. so we'll have to go round a
few issues again. Again, Justin, you have my thanks for taking the
time to explain what you've done.


Earlier, I wrote:

>>Perhaps the special case of a linear, no-op mapping from bus addresses
>>to system memory addresses comes up often enough that it's worth
>>optimizing for.

Justin replied (with context snipped, because it's my text talking
about non-x86 systems both above and below):

>It happens in all cases but to an ISA bus mastering device in a system 
>with more than 16MB of memory for x86 platforms.

I think that's a question of easily verifiable fact, and from where
I'm sitting, it's simply untrue. It may be true _FOR FREEBSD_, but
this is, after all, a discussion about portability.  Justin, here's
what you said at the beginning:

  }I had hoped to share an identical bus dma interface with
  }NetBSD, but I am unwilling to do this so long as the NetBSD interface
  }acrifices speed and memory resources for absolutely no gain in
  }portability.

that was on a NetBSD list (the context is important: it says
what "portability" means).

Justin, I really, sincerely, dont think you are trying to say
something like:

  }I had hoped to share an identical bus dma interface with
  }NetBSD, but I am unwilling to do this so long as the NetBSD interface
  }acrifices speed and memory resources [on x86] for absolutely no gain in
  }portability [on x86].


But with the two otherwise contradictory statemetns that's the way it
comes across.  Justin, I can't beleive someone technically skilled
as you could write something so vacuous.  We  must be talking
past each other.   Can we try and get back on track?



>You somehow believed that the FreeBSD implementation wasn't allocating
>dma maps.


I thought you said they didn't allocate dma maps; that the "common
case" for drivers that communciate the device-dependent S/G data to a
SCSI device didn't need a dmamap and that that they shared a "default"
map.

Again, in my book, what you seem to mean by an "S/G list" is not a
dmamap:

  (i)  If it's in a device-dependent format, then it DOESN'T WORK.
       (or, to be more precise, you incur the hair of a translation
       function from DD to an MI format, which as you pointed out is
       nasty; and on many (most?) NetBSD platforms, you save nothing,
       since the bus layer has to build a NetBSD-style dmamap and stash 
       it away for the duration of the transfer, regardless.

  (ii) If it's not in a device-dependent format, but an MI format,
       then I really, really really don't understand your claims to be
       saving space by eliminating ``unecessary'' duplicated maps
       (one in devive-dependent format, another in MI format).

This is making me less certain about what the gains from your approach
are.  Are we talking past each other yet again?


>  The client always asks for a dma map to be allocated on it's
>behalf.  What the dma map represents is up to the implentation.

Justin, exactly *what* is "the client" in this context?
Is it the chip-driver layer?
The bus-dma layer?
The host-specific portions of the bus-DMA layer?  

Who can get access to the dmamap, if the only way to get hold of it is
via a callback which the *driver* passes in to the bus-dma API?
How can an arbitrary piece of bus-support function translate the
"implementation dependent" dmamap to something device-independent that
the bus-specific DMA layer can handle?  

I sincerely don't see how this would work on a number of NetBSD
platforms.  Perhaps that's my failing, but if this really is workable,
the description so far is doing a good, if unintended, job at hiding
the fact ;)

I also genuinely don't understand what you mean when you talk about
NetBSD's dmamaps being "static".  Are you saying the problem that
they're allocated once and for all, rather than allocated on the fly
for each request and freed after each request?  Is that really the
issue?  If so, I certainly don't think it _has_ to work that way, or
that we'd need to change the API to make it work that way. Am I
mistaken?