Michael L. VanLoon wrote:
> 
> 
> I think, in general, that this is the very core of NetBSD.  NetBSD has
> been fairly conservative, in the respect that things always need to be
> done "correctly", or not at all.  This is a big win in the sense that
> we get some very well designed code, rather than code that "just
> happens" (you might think of a certain OS that starts with
> L.... here).  This is one of the reasons many of us are here.  NetBSD,
> in general, is a _designed_ system.

As somewhat of a counterpoint to this, NetBSD is also seen as the BSD
that runs on new hardware (x86/alpha/sun4m), and on old obsolete hardware
like sun3/vax (and others).  So when a "supported" device on one of the
"supported" architectures doesn't work with a "supported" amount of RAM,
and the ever-ready answer is "buy better hardware", people get irritated.
I have/use a sun3, so no offense intended, but if a broken down old sun3
can be supported, why can't a brand-spanking-new Adaptec 154X be supported?
I don't agree that this falls into the same category as ATAPI, or PCMCIA
or anything else.  The 154X driver has _been here_ since the dawn of time,
yet it has always been "broken" in this respect.

WRT to MD code being implemented, or maybe just "poorly thought out" MD
code, my /usr/src/arch/i386/isa has: ahc_isa.c fd.c joy.c lms.c mms.c
pms.c and PCVT, which are all MD drivers for ISA devices that could just
as easily live on a non-i386.  What is wrong with having a 154X driver
in arch/i386/isa?  The recently-added 'ahc_isa.c' is there.  Perhaps
it would be appropriate to create a new "bounce-buffered" device that
is seperate from the 'aha' device?  Perhaps arch/i386/isa/aha_bb.c?

Regardless, this >16MB issue has *always* been here on the i386 port,
*always* comes up, and *always* is ignored because of MD/MI issues.
A "short-term fix" implemented when this issue first came up would be
several years old already!

Myself, I have bitten the proverbial bullet and gone with EISA and/or
PCI long ago, but I don't feel that everyone should have to.  Just
like I don't feel that sun3 users should buy a sparc 20, or mac68k
users should buy a PPC, etc.

Perhaps at the very minimum change the "DMA out of range" error
message to something more meaningful?  Or perhaps have the driver
print a warning during probe/attach?


-Andrew