> The method used in FreeBSD (and IS relatively machine independent) only
> requires a few 'C' statements in each driver.  The current code calls
> a '386 specific subroutine (which when the motivation arises -- will
> be cleaned up and placed in a machine independent portion of the tree.)

I had gathered that the reason the NetBSD folks hadn't adopted the FreeBSD
approach was exactly this problem; there's an institutional bias against
grotty little 386-dependant hacks (and even against elegant and clever little
386-dependant hacks ;-), and no one has apparently felt the urge to 
go over it and make it machine independant (unfortunately, neither has
anyone in the core group gone and architected a new solution).  (I share
that bias, even though I don't own an Alpha, or an Amiga, or an HP, or...
I've just programmed on so many different architectures (with so few of them
being from Intel :-) that I've come to the conclusion that machine independant
code is, on average, more likely to be correct than (needlessly) machine
dependant code.)

I could be wrong, though; something in the back of my mind is reminding me
that someone said that a central solution was desired, so that each
individual driver didn't need to be independantly larded with code.  There
are advantages and disadvantages to that; if you do the same thing in ten
separate places, you usually end up doing it two or three almost-but-not-
quite-identical ways, plus changes to the underlying scheme require rampaging
through the source code to pick up and change all the uses.  However, to
have common code requires that none of the uses of it be terribly tricky,
and looking at the adaptec code for simultaneously dodging the creaking
limitations of both the ISA bus and Adaptec's half-assed scatter-gather
engine, I wasn't convinced that good, clean, generic code could be done.

So, I don't think it's necessarily silly that NetBSD hasn't adopted the
FreeBSD bounce buffer code; it may just be a combination of a fond hope
that there's a much better approach, and a lack of time spent on finding
that better approach.  On the other hand, the problem has been festering
for quite a while, and the response I saw recently ("if you can afford
more than 16MB of memory, you can afford a better controller") isn't
accurate, either:  I don't think any PCs use 2MB SIMMs (like some Mac
models have), so it's not at all uncommon to upgrade an existing PC to
16MB by buying exactly 16MB of memory, meaning you must gut all of your
existing memory -- having upgraded at all (from 8MB), going from my
current 16MB to 20MB would be free, except that it requires a controller
which is a substantial fraction of the cost of the memory.  That's even
assuming it would *work*, since I've heard lots of horror tales about
what happens when you try to use both of the VLB slots on some PCs (and
considering that my external cache implementation is defective, I'm
rather unwilling to trust that my motherboard gets much of anything else
right).