CAVEAT:  I do not speak for the NetBSD Core team.
Just for myself...


John Dyson writes:

>The bounce code substitutes a BAD physical address for a GOOD one.  It
>handles the case of simple DMAable and non-DMAable ram.  And
>for that purpose, it looks sufficient.  Now the general case of handling
>multiple busses is a problem.  The best thing appears to be to create
>an abstraction that supports the multiple busses.  Couldn't you do
>something similar to vm_bounce_alloc, except provide the bus information --
>thereby giving a hint as to what bus the I/O needs to be routed to/from???

I think part of cgd's objections were:

 * The mapping from a physical address as seen by an I/O device,
   to the 'physical' address written into mapping registers, is
   the identity function for x86 ISA devices.  This isn't true
   for other hardware (Alpha PCI/x86 devices).

 * Some NetBSD platforms have multiple busses, and each bus may
   have a different mapping from I/O bus "physical addresses" to 
   the addresses that need to be written into DMA mapping registers.

and John Dyson continues, later:


>The solution is not a "grotty" hack.  It is sufficent in the simple DMAable
>or non-DMAable case.  It requires little work to understand the code.  The
>code is based upon rebuilding buffers with pages that can have I/O
>done to them -- very simple.  It is called "bouncing".

/* LECTURE MODE ON */

 I have always understood ``bouncing'' to mean a strategy for dealing
with deficient DMA devices that a cannot address all of a machine's
physical memory: that strategy is to allocate a buffer in the DMAable
memory, and then copy the data to its eventual location.  (the obvious
optimization for non-disjoint DMAable and physical-memory spaces is to
eliminate the copy, when the target is in the DMAable range).

IMHO, this is *NOT THE SAME* as dealing with mapping registers for
busses, and mapping a given bus address into an appropriate address
space for a bus; or for managing the scacre resource of mapping
registers, which (talking in the abstract) may be shared amongst
*several* distinct I/O busses; or be duplicated, for some subset of
the busses on a particular machine.

It doesn't  come close to dealing with the scenario of machines
with a *hierarchy* of busses, with mapping registers at distinct
points in the hierarchy.  Which I think some VAXes had. (or have,
depending on your perspective).

It doesn't come close to addressing the issue of dealing with balky
bus-adaptor hardware which, occasionally, spontaneously resets itself,
and for which the contents of all DMA scatter/gather mapping registers
has to be re-programmed before pending I/Os can be restarted or
reissued.

There may well be other issues I  haven't touched on.
For example, some UNIBUS devices require exclusive use of the UNIBUS
whilst an IO operation on them is active.  I don't know  if the
NetBSD/vax port will ever support them; but they do exist.  Heck,
the're even 4.3bsd drivers somewhere.

I also wonder about devices like Sbus-to-VME adaptors, which
presumably have similar issues when mapping DMA.   Of course
some Suns have directly-attached VME buses, not just Sbus-to-VME
adaptors; and it would be regrettable if different drivers
for a given VME device were needed for the two systems.


If one is concerned about these issues -- and I sometimes am -- then
the x86 bounce-buffer strategy used in FreeBSD is not sufficent for
NetBSD's x86 targets.  It's not clear that it's a even useful starting
point for drivers which address these other issues. 
``There are more things in heaven and earth'', &c.

And since *one* of the platforms on which NetBSD ISA drivers
would  be used, is maintained by a former NetBSD Core member,
it's not surprising to *me* that the  NetBSD core team  hasn't
adopted the FreeBSD bounce-buffer code.   I'd hazard a guess that
the NetBSD core team don't think that the FreeBSD code does a
sufficient minimum *for NetBSD*.

>The position of the call to vm_bounce_alloc was carefully chosen to allow
>for replacement as needed.  Since it is not called in many places, it
>is simple to be upgraded.  Note that the only mistake that we(I) made
>was to have no arguments as to the type of I/O occuring.

Either you have a very broad interpretation of "type of I/O occurring"
(e.g., it includes attributes of the bus-connect topology to the
device on which the I/O is occuring, which *isn't* a "type" of I/O),
or your  claim turns out not to be the case.



>The term "hack" being used for FreeBSD things and "design" being used
>for NetBSD things is exactly the reason why there has been problems
>between the teams.  Please try to understand the background and
>reasoning before judging -- and then the people in the teams or groups
>might get along.  I prefer a "hack" that works to a "design" that doesn't :-).

The horizons of the FreeBSD designs are limited -- not unnaturally --
by x86 hardware: there's neither need nor incentive to go further.

Which would you prefer: "hack", or "not adequate for some of the
systems we intend to support"?


>After this "lecture" -- lets not speak prejudicially,, and try to work this
>out in a scolarly fashion.

/* LECTURE MODE  OFF */

Let's all be aware of the design parameters the other side considers
(a) necessary, and (b) important -- if, indeed, the relevant sides
even agree amongst themselves :).