todd,

Please think through this. I think MACHINE_ARCH == mips is a better
decision. not going to change my mind by repeating the same arugments.

mipsel vs mipseb is no bigger a deal than mips32 vs mips64.  THink
about it.  should those show up as different kinds of $MACHINE_ARCH
too?  If not, why not?  Why does that reasoning not _also_ apply to
mipsel vs mipseb? Do you want four flavours of mips "architecture"?

My take is that $MACHINE_ARCH used to lump together two concepts: both
``mips'' (all endianness vs, say, ``m68k'' and `mipseb'' versus ``mipsel''
(and soon mips64 vs mips32?).  

But there are still a lot of meaningful distinctions that get made
based on purely the _architecture_: e.g, in building set-list entries
which depend on the fact that a machine is a "mips", irrespective of
endian-ness.

We need to have two levels of distinction. That much everyone agrees on. 
I'm saying it makes more sense to leave MACHINE_ARCH==mips alone, and
introduce a new way to name and specify the endian-ness.  And (as best
I recall) that was also the final decision last time it came up.  OK?


>The problem is that the same definition of MACHINE_ARCH breaks too much
>stuff *NOT* in the NetBSD src tree.

Doing it your way breaks too much stuoff which is not in the NetBSD
source tree, too. :).

>We use MACHINE_ARCH to determine a set of compatible binaries.  

Umm, no, we don't.  Its been so on the m68k, yes, but only because
there are no little-endian m68ks. That's the whole point.


>We've used
>it before, 

that was the way it was used, yes.

>we're using it now, and we probably will continue to be using it
>that way.   The existing state is breaking that promise that MACHINE_ARCH
>gives.

No, as best I recall, we changed the promise.


>There's a reason GNU autoconf treats mipsel and mipseb as different
>architectures - it _is_ a different software architecture, because the
>binary format and data storage (and probably opcodes too, I don't know) are
>not the same, be it through byte order or not.

The byteorder is different, yes.  Modulo that difference, the binary
format and the opcodes and the data storage _are_ the same, and the
toolchain knows how to cope with that.  _all_ unixoid mips toolchains
know how to deal with that.  Opcodes different? You dont know what
you're talking about.

All we need to do for GNU autoconf is get the right stanzas to compute
mipsel and mipseb at autoconf time (in config.guess or whatever it
is).

Which is how it's always been done, historically: mips vendors havent
supported bi-endian machines, so they all use just "mips" as the
architecture; (or RISC, for ultrix - sheesh) and config.guess guesses
based on the vendor.  we can't do that but we can (and should, imo)
use the hw.byteorder.

You're saying we should kludge $MACHINE_ARCH so that it's is the same
string gnu autoconfigure uses internally, even though autoconfigure
provides tools to figure out its internal "architecture" token.
Sounds like a kludge to me.


>- Toolchain.

_Not_ a problem for ${MACHINE_ARCH} == mips.  Jason's said why,
so have i. this is not an issue.


>- Pkg system.  All of it, particularly in the realm of binary pkgs.

Huh?  _Where_ is it a problem other than for bulding a pathname to
look for prebuilt binary pkgs?  those, yes, we need to fix, but we
need to fix the install system and the set-building tools too. And
there's a lot there which _does_ depend on MACHINE_ARCH.

>- make(1).

MACHINE_ARCH == mips is the right thing to do here.  Tests are for
``is this CPU of the mips flavour'', not for mipsel or mipseb.
(or they test on MACHINE, not machine_arch).

>- uname(1).
> - Third-party software that needs uname(1) for configuration.

Yes, and most of the stuff i've seen over the past 12 years or so
expects "mips", not "mipsel" or "mipseb".