[PATCH] proc: add byteorder file

[PATCH] proc: add byteorder file

[Thomas Weißschuh]

Certain files in procfs are formatted in byteorder dependent ways. For
example the IP addresses in /proc/net/udp.

Assuming the byteorder of the userspace program is not guaranteed to be
correct in the face of emulation as for example with qemu-user.

Also this makes it easier for non-compiled applications like
shellscripts to discover the byteorder.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>

---

Development of userspace part: https://github.com/util-linux/util-linux/pull/1872
---
 Documentation/ABI/testing/procfs-byteorder | 12 +++++++++
 fs/proc/Makefile                           |  1 +
 fs/proc/byteorder.c                        | 31 ++++++++++++++++++++++
 3 files changed, 44 insertions(+)
 create mode 100644 Documentation/ABI/testing/procfs-byteorder
 create mode 100644 fs/proc/byteorder.c

diff --git a/Documentation/ABI/testing/procfs-byteorder b/Documentation/ABI/testing/procfs-byteorder
new file mode 100644
index 000000000000..bb80aae889be
--- /dev/null
+++ b/Documentation/ABI/testing/procfs-byteorder
@@ -0,0 +1,12 @@
+What:		/proc/byteorder
+Date:		February 2023
+KernelVersion:	6.2
+Contact:	linux-fsdevel@vger.kernel.org
+Description:
+		The current endianness of the running kernel.
+
+		Access: Read
+
+		Valid values:
+			"little", "big"
+Users:		util-linux
diff --git a/fs/proc/Makefile b/fs/proc/Makefile
index bd08616ed8ba..c790d3665358 100644
--- a/fs/proc/Makefile
+++ b/fs/proc/Makefile
@@ -12,6 +12,7 @@ proc-$(CONFIG_MMU)	:= task_mmu.o
 proc-y       += inode.o root.o base.o generic.o array.o \
 		fd.o
 proc-$(CONFIG_TTY)      += proc_tty.o
+proc-y	+= byteorder.o
 proc-y	+= cmdline.o
 proc-y	+= consoles.o
 proc-y	+= cpuinfo.o
diff --git a/fs/proc/byteorder.c b/fs/proc/byteorder.c
new file mode 100644
index 000000000000..39644b281da9
--- /dev/null
+++ b/fs/proc/byteorder.c
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <asm/byteorder.h>
+#include <linux/fs.h>
+#include <linux/proc_fs.h>
+#include <linux/seq_file.h>
+#include "internal.h"
+
+#if defined(__LITTLE_ENDIAN)
+#define BYTEORDER_STRING	"little"
+#elif defined(__BIG_ENDIAN)
+#define BYTEORDER_STRING	"big"
+#else
+#error Unknown byteorder
+#endif
+
+static int byteorder_seq_show(struct seq_file *seq, void *)
+{
+	seq_puts(seq, BYTEORDER_STRING "\n");
+	return 0;
+}
+
+static int __init proc_byteorder_init(void)
+{
+	struct proc_dir_entry *pde;
+
+	pde = proc_create_single("byteorder", 0444, NULL, byteorder_seq_show);
+	pde_make_permanent(pde);
+	return 0;
+}
+fs_initcall(proc_byteorder_init);

base-commit: 5aaef24b5c6d4246b2cac1be949869fa36577737
-- 
2.38.1

Re: [PATCH] proc: add byteorder file

[Greg KH]

On Tue, Nov 01, 2022 at 01:50:43AM +0100, Thomas Weißschuh wrote:
> Certain files in procfs are formatted in byteorder dependent ways. For
> example the IP addresses in /proc/net/udp.
> 
> Assuming the byteorder of the userspace program is not guaranteed to be
> correct in the face of emulation as for example with qemu-user.
> 
> Also this makes it easier for non-compiled applications like
> shellscripts to discover the byteorder.
> 
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>

Why not put this in /sys/kernel/ instead?  What does this have to do
with /proc/ other than it's traditionally been the dumping ground for
stuff like this?  :)

thanks,

greg k-h

Re: [PATCH] proc: add byteorder file

[Thomas Weißschuh]

On 2022-11-01 05:34+0100, Greg KH wrote:
> On Tue, Nov 01, 2022 at 01:50:43AM +0100, Thomas Weißschuh wrote:
> > Certain files in procfs are formatted in byteorder dependent ways. For
> > example the IP addresses in /proc/net/udp.
> > 
> > Assuming the byteorder of the userspace program is not guaranteed to be
> > correct in the face of emulation as for example with qemu-user.
> > 
> > Also this makes it easier for non-compiled applications like
> > shellscripts to discover the byteorder.
> > 
> > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> 
> Why not put this in /sys/kernel/ instead?  What does this have to do
> with /proc/ other than it's traditionally been the dumping ground for
> stuff like this?  :)

The main reason to put it in /proc was because the data it helps to interpret
is also in /proc.

But /sys/kernel looks good, too. I'll change it to that.