> > While I have your attention, a couple of more random questions:
> > 
> >  o I assume the output of "uname -m" on NetBSD will be "mips" for
> >    all machines with a MIPS processor, irrespective of its
> >    endianness or wheter it's a MIPS1 or MIPS3?


No, it won't.  It'll be "pmax" on pmaxes, "arc" on arc, "news" or
"newsmips" on SONY news machines, "sgi" on SGI machines, and for the
same reason that it's "hp300" or "sun3" or "amiga" or whatever on m68k
platforms.



>This is the issue here, and I believe that both "mips" and OBJ_ARCH are
>_wrong_.

Jason, it is _not_ ``the'' (only) issue here:.There are other
intimately-related issues, some of which you seem ot have agreed is
not good engineering.

Todd is arguing for splitting "mips" into "mipsel/mipseb/mipseln32/
mipsebn32/mipsel64/mipseb64", and I beleive that is is equally _wrong_.


>Can someone just make the change to make them "mipsel" and "mipseb" and
>be done with it?  Otherwise, I'll just do it myself.


If they do, it'll break all mips-related uses of ${MACHINE_ARCH} in
Makefiles, walking into arch/mips/ sub-directories, set-list
construction, tests for ${MACHINE_ARCH} in ONLY_FOR_ARCHES, and so on.

If those get broken I'm very tempted to back it out until they get
fixed, so makefile or C-source clients can just test for "mips" or
``#ifdef __mips__'' again.  It's just not as simple as Jason makes out.

If we want to break the invariant that ${MACHINE_ARCH} == uname -a,
well, that's one thing.  

Or if we want to institute a new variable that replaces all uses of
${MACHINE_ARCH} except two or three uses in the package system and in
sysinst, that's something else too.