On 01/20/2015 18:05, David Daney wrote: > On 01/19/2015 01:02 AM, Joshua Kinard wrote: >> From: Joshua Kinard <kumba@xxxxxxxxxx> >> >> This is a small patch to display the CPU byteorder that the kernel was compiled >> with in /proc/cpuinfo. > > What would use this? Or in other words, why is this needed? It was a patch I started including years ago in Gentoo's mips-sources, and just never thought much about. I know it was submitted several times in the past, but I can't recall what, if any objection was ever made. No harm in sending it in again... > 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 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. --J >> >> Signed-off-by: Joshua Kinard <kumba@xxxxxxxxxx> >> --- >> arch/mips/kernel/proc.c | 5 +++++ >> 1 file changed, 5 insertions(+) >> >> This patch has been submitted several times prior over the years (I think), but >> I don't recall what, if any, objections there were to it. >> >> linux-mips-proc-cpuinfo-byteorder.patch >> diff --git a/arch/mips/kernel/proc.c b/arch/mips/kernel/proc.c >> index 097fc8d..75e6a62 100644 >> --- a/arch/mips/kernel/proc.c >> +++ b/arch/mips/kernel/proc.c >> @@ -65,6 +65,11 @@ static int show_cpuinfo(struct seq_file *m, void *v) >> seq_printf(m, "BogoMIPS\t\t: %u.%02u\n", >> cpu_data[n].udelay_val / (500000/HZ), >> (cpu_data[n].udelay_val / (5000/HZ)) % 100); >> +#ifdef __MIPSEB__ >> + seq_printf(m, "byteorder\t\t: big endian\n"); >> +#else >> + seq_printf(m, "byteorder\t\t: little endian\n"); >> +#endif >> seq_printf(m, "wait instruction\t: %s\n", cpu_wait ? "yes" : "no"); >> seq_printf(m, "microsecond timers\t: %s\n", >> cpu_has_counter ? "yes" : "no");
