Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 01/26/2015 06:53 AM, Maciej W. Rozycki wrote:
On Mon, 26 Jan 2015, Ralf Baechle wrote:

  Well, several MIPS processors can reverse the user-mode endianness via
the CP0.Status.RE bit; though as you may be aware it has never been
implemented for Linux.  Otherwise it would obviously have to be a
per-process property (and execve(2) could flip it back).

As posted previously that was why I removed it from /proc/cpuinfo.  And
yes, I had a simple prototype to use the RE feature.  Even in the limited
form I had it was impressively ugly and it became clear it would never
be upstreamable.

  Out of curiosity -- what was there that made it so ugly?  The need for
case-by-case individual handling of byte-swapping the qualifying members
of syscall and signal data structures such as `struct stat'?  Obviously
not alignment trap fixups, these are trivial to handle.  And I think
pretty much everything else is endianness-agnostic.


I think *nothing* is endianness-agnostic. The instruction set reference manual (MD00087 MIPS® Architecture For Programmers Volume II-A: The MIPS64® Instruction Set, Revision 5.02) is a little cryptic, but I think looking at the LB instruction shows how it works. OCTEON is known to implement this and has been verified to work this way.

aligned 64-bit loads and stores are endianness invariant.

32-bit loads and stores have even and odd words swapped in the opposite endianness (low order 3 address bits are XOR 4).

16-bit loads and stores half words scrambled in the opposite endianness (low order 3 address bits are XOR 6).

8-bit loads and stores are scrambled such that the low order 3 address bits are XOR 7 in the opposite endianness.

The result that all byte array data is scrambled when switching endianness.

This means that all read(), write() and similar calls could *not* access the user data in-place in the kernel. The kernel would have to swap around the bytes before using it. mmap() of the same file in processes of opposite endianness would be impossible, as one of the processes would see scrambled data.

For this reason, it really only makes sense to have the kernel and user-space use the same endianness.

And because kernel and userspace must have the same endianness, the endianness can be probed in userspace without consulting the kernel.

David Daney





[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux