Subject: Re: Driver hierarchy
To: Chris G. Demetriou <cgd@netbsd.org>
From: Todd Whitesel <toddpw@best.com>
List: port-arm32
Date: 03/18/2000 21:10:44
> In fact, there _are_ known differences between the ports, so the exact
> same binary sets probably won't just work 100%.
...
> same MACHINE_ARCH is not even a cross build.  it's a native build.

Okay, so how do I build a sun3 kernel+userland on a next68k box?
Is that a native build??

Native for the compiler, and native for the entire build system, are two
different levels of native-ness.

> these are artifacts of existing bugs.  if you want to make the world a
> better place, you have to push it in the right direction and help fix
> the bugs.  propagating the existing buggy system is not a plus.

What's wrong with arm32 other than the monolithic organization?  I don't
think that is necessarily a bug. I would think that it actually prevents
bugs by forcing everything outside the kernel configs to be shared.

Sure, it straightjackets things a bit, like if someone only cares about
RISCPC and doesn't want any SHARK or VOYAGER specific bits to be built. That
is easily fixed by adding a mechanism to select which should be skipped.

I note that hpcmips is currently working at elminating duplication relative
to pmax, even to the point of mandating FPU emulation on hpcmips. While I
wonder if this is a little extreme, I think it really does make more sense
to move towards "NetBSD/mips with hpcmips and pmax platform support", and
away from "NetBSD/pmax and NetBSD/hpcmips".

Todd Whitesel
toddpw @ best.com