> > The only real win I see in having fat binaries is that they should be
> > halfway newbie proof. I think they're especially interesting for the
> > MIPS project. For MIPS we already have all binaries in two flavours,
> > little and big endian. You can wait for the first message on this list
> > "I just installed this new cool program xy on my Linux/MIPS box but it
> > doesn't work ..." Other than that fat binaries won't bring much win
> > as they bring nothing that isn't possible with conventional means.
>
> How hard would it be to make the Linux/Mips kernel run either big or
> little endian binaries?
You mean to make it run binaries with the reversed byte order of the
kernel? Well, this was one of too many projects that were in the works
for Mips's own operating system RISC/os and finally ruined the company
so that SGI bought them ...
You have to rework every access to the userspace. Luckily enforced by
the 386 segments as used in Linux all userspace accessed have been
abstracted out with put_user/get_user macros. The evil part is to go
through the zillions of ioctls in the kernel and to find and fix
everything that handles bitfields or simply copies structs to/from
userspace. It's doable, but it's not easy. It's on my to-do list for
the kernel though ...
Such a bi-endian kernel is attractive especially for all the little
endian MIPS systems built with NT in mind so that they can run the
big endian IRIX or ABI conforming software. It's also good because
it will make the access to commercial software easier.
Ralf