Todd Whitesel <toddpw@best.com> writes:
> > 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??

Right now, in theory (i.e. not having looked into it) if you have to
do more than set MACHINE in the environment, there are bugs.  That's
how it should work.

The Right Thing, of course, is to have the user-land programs
completely common, i.e. there's no difference at all between a sun3
userland and a next68k userland.


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

And what in the build system knows about the machine type, other than
by the setting of MACHINE?  (Certainly, things could depend on the
includes installed because of MACHINE, etc., but those are fixed by
setting MACHINE properly and e.g. doing a DESTDIR-set build, no?)


> > 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.

the monolithic organization is one serious one.  one hallmark of a
single value of MACHINE is that you can use a single GENERIC kernel
across all of the machine types supported.

look at the way the code is structured.  it's basically as if they
were all different machines, but they're just jumbled together.

Also, actually having too many things shared is just broken.  how many
optimization opportunities are missed because of the 'one code fits
all' policy there?


> 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.

OK, look at this another way: 

what's the right binary -- you can pick only one -- to install in a
NetBSD/arm32 kernel distribution set?


> 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".

well, more like mipsel, but direction agrees with what I consider
'right': MACHINE_ARCH common with binaries that interoperate, but
different MACHINEs for different system families and non-interoperable
kernels.


cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.