Commit Message
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
base-commit: 5aaef24b5c6d4246b2cac1be949869fa36577737
Comments
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
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.
new file mode 100644
@@ -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
@@ -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
new file mode 100644
@@ -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);