>How likely is it that the code for bounce buffers will ever be needed
>in the alpha port?  Has DEC actually been shipping this machine with outdated
>disk controllers that can only address 16-bits of memory?
>
>It seems to me that we're trying to integrate support for obsolete technology
>(which is what the bounce buffer code is) into modern platforms that will
>never need to use such code.  Maybe its time we weighed the tradeoffs
>between waiting for the perfect implementation and satisfying user needs in
>the here and now.  What we should have is a criterion for when it's
>appropriate to insist upon the ideal of architectural independence for
>portions of NetBSD.

Not at all saying that bounce buffer code for the i386 isn't something that we
shouldn't have, but it should be noted that there are at least 2 different 
machines in my house, that *DO* have an ISA bus on them, are *NOR* an Alpha or
an i386 box.  I'd like to see ports on these machines in the future, and despite
the fact that I don't have the first clue whether either of these machines
have problems with DMA >= 16Mb, I'd think it's a dangerous trend to allow the
ISA code to revolve around the i386.  There is a fine line between having lofty
goals, and getting things done, but it should be noted that one reason 
why NetBSD is running on all the platforms that it is, is because people here
make their best attempt at making sure things are as architecutre independant
as possible.  I'm sure this has muddied the waters enough, so I'm going to get
down off of my soapbox, but IMHO, this is going to be an continuing debate,
if it's not Bounce Buffers, it's going to be something else.  NetBSD core, and
people working on it need to decide whether to do things the "holy" way, or
the "it works" way, or something in between.

>
>As a first step, why not consider the following:
>
>If a piece of code
>
>	o  has a clear and present need to be supported across all
>		architectures (example:  code for a unified buffer cache)
>OR
>	o  isn't currently needed across all architectures but is state of
>		the art technology and will probably be needed in the future
>		(example:  machine-independent portions of an ATM driver).
>
>then, and only then, does it make sense to insist on a pure implementation.
>
>The bounce buffer extensions don't fit into either of these categories.
>That being the case, is it really advisable that we should hold out for
>an architecturally-pure implementation instead of incorporating a perfectly
>good single-platform solution?

-------------------------------------------------------------------------------
Jeremy C. McDermond					mcdermj@xenotropic.com
Xenotropic Imaging Systems
-------------------------------------------------------------------------------