Subject: Re: [NetBSD] 1.1 386 Hardware
To: John Dyson <firstname.lastname@example.org>
From: Jonathan Stone <email@example.com>
Date: 11/08/1995 11:09:48
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
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 :).