On Thu, 4 Dec 1997 email@example.com wrote:
> On Thu, Dec 04, 1997 at 12:31:05AM -0500, Alex deVries wrote:
> > Is the creation of a mipsel type reasonable?
> Definately, only the fact that there are more important things to do did
> so far keep me from doing so.
> While almost all MIPS CPUs can run in both byteorder some systems like
> the Acer Pica or DECstations don't support this CPU feature. There is
Right. So they'd be of arch 'mips'.
> still another CPU feature that allows to run the other flavor of software
> in usermode but supporting it not a Sunday afternoon hack.
Hm. RPM makes no diffrentiation between user and non-usermode apps. So,
I'd say we'd mark this as 'mipsbi'. The only restriction is with kernel
RPMs, and there aren't a lot of those.
> It requires
> going through _all_ the kernel code and possibly fixing the byteorder
Nobody wants that.
> Unless the rpm gurus think there is a better way to do things - yes, it
> looks right to me. The other thing that needs to be done is to teach
> rpm how to recognice the various system flavours. Currently rpm relies
> on uname() returning "mips" and therefore thinks MIPS is always MIPS.
That shouldn't be too difficult to build into .configure. For everything
matching mips:*, configure should do a byte order execution check. If it
can do mipsel, it's little endian. If it can do bigendian, it's mips. If
it can do both, it's mipsbi. Is there an easy way to do a test like
> Have to take a look at the rpm sources - is there an official way to
> teach rpm about incompatible variants of the same CPU architecture?
Yes, sort of.
There should be two binary formats defined in /usr/lib/rpmrc
arch_canon: mips: mips 4 (already defined)
arch_canon: mipsel: mipsel 11
arch_compat: mips: noarch
arch_compat: mipsel: noarch
arch_compat: mipsbi: mips mipsel
> Modifying uname() to return "mipsel" etc. is a bad choice. For most
I agree. I think we should just patch the configure script to do a
translation to mips, mipsel or mipsbi, as I described above.