>o SGI has traditionally returned mips for big endian.

SGI never supported little-endian mips (not for unix).

>o Linux/SGI uses mips for the big endian ports and mipsel little
>  endian ports.  It uses these values for the rpm packages.

Maybe so. AFAIK, 4.4bsd used mips for both.

>o OpenBSD/arc seems to use arc, I think (my openbsd machine is off to
>  keep the room cool).

Eek. For machine, or ${MACHINE_ARCH}?

>o RISC/OS returns mips and mipsel, if I recall some mail in the linux
>  list correctly.  However, don't quote me on that...

That sounds .. odd to me, but i'd buy it.

One problem with using "mips" for mipseb is, what do we call the
release(7) directory endian-neutral mips files (manpages, ???)

>I don't know if this makes a difference to people, but I thought I'd
>mention it.


It would be nice if they didnt care. Handling the ioctls sucks: you
have to look at the datatypes in a struct argument and byteswap
them. and if the ioctl arg points to structs, you have to allocate a
temp, and copy/byteswap what's pointed to into the temporary.  And on
return, copy/swap them out again.

It really is just like doing an RPC.

>I do think that there needs to be two different values, unless the
>kernels in question don't care.  And I know that isn't the case for
>NetBSD 1.3.x....

Why do there need to be two values for ${MACHINE_ARCH}, though?
What happens when we go to 64-bit (mips3) instructions?
Does that mean we have four values?  Is that good engineering?
If there was an answer to that,  I missed it.