> > to get a Linux/MIPs distribution. Furthermore, givem that Linux/MIPs
> > will run IRIX elf binaries, we might be able to merge the Freeware and
> > Linux/MIPs efforts - they have a lot of overlap. Something to think
> > about.
> This raises a good question - what is the relationship between the SGI port,
> a port to Digital MIPS/TurboChannel machines, and the MIPS/PC port (that
> works on MIPS machines with PCI/EISA buses)? Will they all be the same
> endian? Should binarises be comaptible? What about sources such as libc
> and the kernel syscall interface?
The main issue in achieving binary compatibility accross all Linux/MIPS
targets is the byte order. For some machines (Mips Magnum 4000, Olivetti
M700-10, SNI RM series and others more) the byte order for the kernel is
configurable. For other it is fixed. This is often the case for machines
that were built with NT in mind.
The MIPS architecture offers us the nice feature of switchable byteorder
for usermode. Thus we have a way to run software from other systems with
differing native byte order. In other words: it's technological possible
but it's not implemented yet.
The MIPS ABI which to support is one design goal for Linux/MIPS supports
only big endian systems while current Linux/MIPS implementations are all
little endian. This single fact shows Linux/MIPS doesn't currently
conform to the ABI but it will be relativly easy to do so in the future.
The ABI explicitly forbids direct syscalls from the usercode into the
kernel. Instead every program is supposed to be linked with the shared
library libc.so.1 which contains the actual interface to the kernel.
Linux/MIPS currently uses the GNU libc which is far being compliant
to the ABI.
Nevertheless Linux/MIPS contains an (currently on partial implemented)
syscall interface that provides not only the syscalls known from the
Linux/i386 implementation - it also features the same syscall conventions,
numbers and more as implemented in IRIX and other MIPS UNIX systems.
Call it a kludge but it can make things easier.