On 2022-11-01 14:29+0100, Greg KH wrote: > On Tue, Nov 01, 2022 at 02:04:01PM +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. > > Your subject says "proc" :( Will fix. > Also you do not list the new file name here in the changelog text, why > not? Please see below, or am I missing something? > > > > Signed-off-by: Thomas Weißschuh <linux@xxxxxxxxxxxxxx> > > > > --- > > > > Development of userspace part: https://github.com/util-linux/util-linux/pull/1872 > > > > v1: https://lore.kernel.org/lkml/20221101005043.1791-1-linux@xxxxxxxxxxxxxx/ > > v1->v2: > > * Move file to /sys/kernel/byteorder ^^^^^^^^^^^^^^^^^^^^^^ New filename in changelog above > > --- > > .../ABI/testing/sysfs-kernel-byteorder | 12 ++++++++++++ > > kernel/ksysfs.c | 18 ++++++++++++++++++ > > 2 files changed, 30 insertions(+) > > create mode 100644 Documentation/ABI/testing/sysfs-kernel-byteorder > > > > diff --git a/Documentation/ABI/testing/sysfs-kernel-byteorder b/Documentation/ABI/testing/sysfs-kernel-byteorder > > new file mode 100644 > > index 000000000000..4c45016d78ae > > --- /dev/null > > +++ b/Documentation/ABI/testing/sysfs-kernel-byteorder > > @@ -0,0 +1,12 @@ > > +What: /sys/kernel/byteorder > > +Date: February 2023 > > +KernelVersion: 6.2 > > +Contact: linux-fsdevel@xxxxxxxxxxxxxxx > > Why is this a filesystem thing? I don't see how that is true. For procfs this is the list that was repored by get_maintainer.pl, so I reused it. I'm not entirely sure whom to put here. Myself? You? Some mailing list? > > +Description: > > + The current endianness of the running kernel. > > + > > + Access: Read > > + > > + Valid values: > > + "little", "big" > > +Users: util-linux > > diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c > > index 65dba9076f31..7c7cb2c96ac0 100644 > > --- a/kernel/ksysfs.c > > +++ b/kernel/ksysfs.c > > @@ -6,6 +6,7 @@ > > * Copyright (C) 2004 Kay Sievers <kay.sievers@xxxxxxxx> > > */ > > > > +#include <asm/byteorder.h> > > #include <linux/kobject.h> > > #include <linux/string.h> > > #include <linux/sysfs.h> > > @@ -20,6 +21,14 @@ > > > > #include <linux/rcupdate.h> /* rcu_expedited and rcu_normal */ > > > > +#if defined(__LITTLE_ENDIAN) > > +#define BYTEORDER_STRING "little" > > +#elif defined(__BIG_ENDIAN) > > +#define BYTEORDER_STRING "big" > > +#else > > +#error Unknown byteorder > > +#endif > > + > > #define KERNEL_ATTR_RO(_name) \ > > static struct kobj_attribute _name##_attr = __ATTR_RO(_name) > > > > @@ -34,6 +43,14 @@ static ssize_t uevent_seqnum_show(struct kobject *kobj, > > } > > KERNEL_ATTR_RO(uevent_seqnum); > > > > +/* kernel byteorder */ > > +static ssize_t byteorder_show(struct kobject *kobj, > > + struct kobj_attribute *attr, char *buf) > > +{ > > + return sprintf(buf, "%s\n", BYTEORDER_STRING); > > sysfs_emit() please. The rest of the file also uses plain `sprintf()` everywhere. I'll fix my patch and send a second commit to migrate the other users. > And this really is CPU byteorder, right? We have processors that have > devices running in different byteorder than the CPU. userspace usually > doesn't need to know about that, but it might be good to be specific. Will do. Thomas
