I was wondering that when you install a R5K Indy with 6.5.22m, which mips version would the /unix kernel be?

I need this to autoguess mips3/mips4 support in the openssl config script because the old script has been disabled, probably due to some complexity reason, thus defaulting always to -mips3. A safe choice, but not if you want to use with other applications which require mips4 support.

For some reason, there isn't an 'easy' way to determine the maximum mips version support for an IRIX system. There is hinv -t cpu which gives the MIPS CPU model string and uname -m which gives the hardware platform, but both need work and the IP24 hardware platform is inconclusive, because of R5k support.

Any pointers for a super easy one (or two) command syntax printing this would be appreciated.

japes wrote:Does this help you at all? I see it's 6.5.22f, but I doubt that matters.

Yes it does. Stunning. This means that even if the R5K in the Indy is capable of mips4, its Indy kernel is mips3 (and i assume most if not all other subsystems).

This makes sense if you look at compatibility between the available processors in the Indy and Indigo2. Since they share a common base, the MC Rev3 controller ASIC, all installations must support the lowest common denominator which is mips3 for the R4000/4400 in the Indigo2 and the R4000/4600/4400/5000 in the Indy.

But this also implies that the level of mips instruction set support of the kernel cannot be used for the mips support of the processor. Drat I'll stick with the bulky script in openssl for now.

[EDIT] The O2 result is interesting in that it looks like SGI has decided that all IRIX platforms get the mips3 version and IRIX64 are mips4. Since the O2 only supports IRIX, the kernel is mips3, even for a R10k processor. I think that the kernel should not benefit much from moving to mips4, so they refrained form making separate kernel support for those systems.

Oh i forgot. Somewhere, sometime, the O2 could support a R4600 CPU, maybe this is the reason why it stayed mips3 as well.

The "file" command doesn't analyze the binary for what CPU it was compiled for, it simply decodes some bits in the header.Those bits are used by the loader to prevent you from running binaries that wouldn't support your machine. But the kernel is never loaded like this. It is read into memory by the PROM and jumped into using a totally separate mechanism. So the architecture flags are pretty meaningless and don't tell you anything.

I think SGI tended to build things lower down unless there was a significant performance gain. I remember being surprised that IRIX 6.2 came back as MIPS-2 (can't remember if this was an IP22, IP28 or IP25).Couldn't you do a check for hinv -t cpu output for "R5000" to verify Indy R5k rather than the more convoluted bit of the initial script?