2022-11-01 01:40:57

by Thomas Weißschuh

[permalink] [raw]
Subject: [PATCH] proc: add byteorder file

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 <[email protected]>

---

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: [email protected]
+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



2022-11-01 05:08:34

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH] proc: add byteorder file

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 <[email protected]>

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

2022-11-01 05:10:29

by Thomas Weißschuh

[permalink] [raw]
Subject: Re: [PATCH] proc: add byteorder file

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 <[email protected]>
>
> 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.