In message <199512282106.PAA00946@darkwatch.flame.org>, "Michael Graff" writes:
> 
> >Rather than continuing to wait for someone to be struck with a divine
> >revelation of a perfectly architecture-neutral scheme, it seems like the
> >most sensible approach at this point is to choose a good *existing* strategy
> ,
> >commit it as an architecture-and-card-specific fix; *then* work on improving
> >it to be as general as it ought to be.  Who knows, maybe that would provide
> >the impetus for someone to actually *do* that last bit of work; the current
> >strategy certainly isn't making any progress!
> 
> I thought about that method, but it just won't work.  I tend to agree
> with the core's decision on that one though.
> 
> What I do NOT like is the asumption that `someone will fix it sooner
> or later' because I just don't think there is one person who can or
> will do this.
> 
> If chris (the port master for alpha last time I checked) would work
> with me on getting things in there, I think I can do the i386 side.  I
> do NOT want to make changes to the alpha side that will just be
> rejected -- this is called a waste of time.  Would someone willing to
> do the alpha side PLEASE speak up!
> 

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.

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?