> It's my concern that the attitude that "the PC sucks" prevents
> things like bounce buffers and other useful features from being
> included in this very clean source tree.

I don't think Charles said anything like that.  With bounce buffers
specifically, what has prevented them making it into the source tree
(so far) has been the fact that all of the solutions presented so far
have been very i386 specific, when it is (in fact) a very general
problem.  Chris (?) apparently is on the way to devising a reasonably
general solution that should give bounce-buffers to *all* the
architectures on which ISA has been inflicted.  The other presented
solutions would have resulted in all the ISA drivers splitting into
multiple architecture- specific variants, making it very hard to keep
them all up to date with bug fixes.  If you have only one or two
architectures, that may not seem so bad; it would be disastrous for
NetBSD, though.  But in addition, it has been my personal observation
over nearly two decades of computer work that code designed for
portability is just plain more likely to be *correct* than code that's
knocked out with one architecture in mind; not only does that require
you to foreswear a lot of tricks that often end up being mistakes even
on the target architecture, but the additional care that effort
requires gives you time to find machine-independant bugs by inspection
as well.

There are, perhaps, some machine-specific tweaks that have been met
with unjustified disdain.  One *might* argue that the fast-interrupt
code for the serial ports which was recent mentioned is a possible
candidate for that status; interrupts are just one of those things
that no two architectures are going to agree on, and where careful
tuning can really pay off (especially when you have the gross
misdesigns present in, well, CERTAIN computer architectures).  On the
other hand, had the com.c driver bifurcated before the somewhat more
fundamental FIFO changes were done, integrating those changes into two
drivers (or, more accurately, moving those changes from one of the
drivers to the other) would have been a lot of work.  Now that com.c
has a hope of performing well, maybe *this* is the time to give it an
interrupt fast path ;-).  *Maybe*.