On Mon, Jan 26, 2015 at 08:06:35AM +0000, Maciej W. Rozycki wrote: > On Tue, 20 Jan 2015, Joshua Kinard wrote: > > > > Userspace C code doesn't need this as it has its own standard ways of > > > determining endianness. > > > > > > If you need to know as a user you can do: > > > > > > readelf -h /bin/sh | grep Data | cut -d, -f2 > > I tend to use `file /sbin/init' if I need to check it for some reason -- > less typing. ;) > > > This would only tell you the endianness of the userland binary, not of the > > kernel. While they should be one and the same (otherwise, you're not going to > > get very far anyways), they are, technically, distinctly different properties. > > 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. Right now MIPS is not making much use of sysfs. Endian information and other runtime CPU configuration probably should go there. Detecting the size and associativity of cache lines, changing the cache line size, more control over VPEs in multithreaded kernels come to mind. > What you may find more interesting, we actually used to include this > information in /proc/cpuinfo, long ago, and I believe it was removed for > the very reason of the existence of this reverse-endianness feature. > Which I find sort of weak an argument given that we don't support this > stuff anyway, but given the simple ways to extract this information from > elsewhere (/proc/config.gz is another candidate place) I have doubts if > having it in /proc/cpuinfo adds any value too. Not that I'd object it > strongly either though. > > See: > > commit 874124ebb6309433a2e1acf1deb95baa1c34db0b > Author: Ralf Baechle <ralf@xxxxxxxxxxxxxx> > Date: Sun Dec 2 11:34:32 2001 +0000 > > Merge with Linux 2.4.15. > > -- which actually makes me wonder what happened here as Linus's 2.4.15 > change does not include any of this stuff. Only 2.4.19 does, 8 months > later -- a CVS to GIT conversion problem? In those days I only sent patches upstream very rarely because committing to CVS was easy - but extracting patches, breaking the up in useful patches and submitting them upstream was so painful. Honestly, the CVS archive only began to be really useful after it was converted to git! The conversion to git is as accurate as I possibly could do it and includes the entire tarball and patch history as well as the linux-2.0 repository. Linux 2.0 lived in a separate repository because it was created for around 2.1.73 when it became clear that 2.2 was still going to take a long time. The conversion was done custom conversion tools due to the limitations of the tools that were available at the time. Ralf
