> 
> > 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.)
> 
Firstly, the code *must* be machine dependent in a general case because of the
spectre of mapping registers, various DMAable/non-DMAable regions,etc.
Secondly, the FreeBSD solution is currently a "specific" solution to
a general problem -- and the FreeBSD solution is very easily generalized,
and I guess we'll have to wait for FreeBSD to implement the general solution.
Or perhaps, you can learn what I have been thinking of, and profit from
my experience and ideas.

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".  To generalize
the capability requires the addition of low-level code to support what
is needed.  More than likely, the routines can be enhanced to
support both mapping and bouncing with little more than the effort to
write the underlying support routines.  Perhaps a vector of support
routines is in order to handle the various cases.

Something like "vm_bounce_alloc(struct buf *, I/O description);".  Name
here is not important -- but the functionality is.

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.

/* FLAME ON */
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 :-).
/* FLAME OFF */

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

John
dyson@freebsd.org