>If mips64 will require a different binary format, it to should be a
>different MACHINE_ARCH as well.

That doesn't answer my question, Todd.  The "binary formats" are all
different insofaras they have different ELF tags. No more and no less
different than sparc v8 vs 64-bit sparc v9.


>Pkgs care less about endianness.  Third party software cres less about
>endianness.

So they don't need to know about endian-ness. Fine. They can use
MACHINE_ARCH == mips. I tend to agree.  Specially since that's what
they already test for.  I dont understand what you are arguing for here.


>MACHINE_ARCH SHOULD SPECIFY A COMPATIBLE SET OF BINARIES, AND IS DOCUMENTED
>TO DO SO.  That's a far more long-standing promise than the mips platforms
>have even existed.

The documetnation needs to be fixed, then.  

As best I recall, the person who came up with the original promise
even says that bi-endian machines werent' considered then, and that
after due consideration, we were better off leaving MACHINE_ARCH
alone.  Have you checked the archives of that discussion yet?


Nobody disagrees that we need to distinguish both MACHINE_ARCH and
MACHINE_ARCH_ENDIAN (or whatever it ends up being called).  All I'm
saying is that we *agreed* that leaving MACHINE_ARCH alone, and using
MACHINE_ARCH_ENDIAN (or whatever) where the distinction is necssary
was a better choice than the one you propose.  We had that discussion
and a decision was made.  Why are we arguing it all again?


>This works only because we _happen_ to use the same basic toolchain format
>(ELF) on mipsel and mipseb.  If one of them were still a.out, this rgument
>would go out the window.


That's just wrong, in a way which cuts to the heart of the disagreement. 

 We use the same toolchain format on mipsel and mipseb because they
_ARE_ the same architecture.  If there'd been big-endian mips systems
using a.out, they would've cut over to static ELF at the same time.
Same for shared libs.  Same for when we cut over to elf.ld_so.
It's one MACHINE_ARCH, because they _are_ one architecture.

There's one set of kernel support, one toolchain, and it's all kept in
step across mipsel and mipseb.  Just as it is for m68k. Despite the
fact that there's 040 instructions that won't run on an 030/020, and
vice-versa. Does that make them different MACHINE_ARCHes?
I dont think so.


I really think MACHINE_ARCH on a mips doesn't mean what you seem to
think it means.



>Then why does the pkg system rely on the same promise?  

Because it hasn't been upgraded to reflect the new promise?
And (again) _where_ does it use it?


>Why does GNU  software?

Point of fact, Todd: it *doesn't*.  

GNU software uses a layer which translates from whatever the OS gives
it to GNU's own internal identifiers. Which encode architecture,
machine, vendor/OS, *AND* endian-ness *AND* 32 vs 64-bit, where
appropriate.  Changing our MACHINE_ARCH to match what the mips
toolchain uses internally -- when autoconfigure has layer specifically
to do that mapping -- is a kludge, pure and simple.

All we need to do is change the autoconfig code which guesses
byteorder from the machine and/or vendor, to test for the byteorder
via sysctl.  And even so it should affect only the deafult vector.
I honestly dont see a problem here at all.