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
v1: https://lore.kernel.org/lkml/[email protected]/
v1->v2:
* Move file to /sys/kernel/byteorder
---
.../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: [email protected]
+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 <[email protected]>
*/
+#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);
+}
+KERNEL_ATTR_RO(byteorder);
+
#ifdef CONFIG_UEVENT_HELPER
/* uevent helper program, used during early boot */
static ssize_t uevent_helper_show(struct kobject *kobj,
@@ -215,6 +232,7 @@ EXPORT_SYMBOL_GPL(kernel_kobj);
static struct attribute * kernel_attrs[] = {
&fscaps_attr.attr,
&uevent_seqnum_attr.attr,
+ &byteorder_attr.attr,
#ifdef CONFIG_UEVENT_HELPER
&uevent_helper_attr.attr,
#endif
base-commit: 5aaef24b5c6d4246b2cac1be949869fa36577737
--
2.38.1
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" :(
Also you do not list the new file name here in the changelog text, why
not?
>
> Signed-off-by: Thomas Wei?schuh <[email protected]>
>
> ---
>
> Development of userspace part: https://github.com/util-linux/util-linux/pull/1872
>
> v1: https://lore.kernel.org/lkml/[email protected]/
> v1->v2:
> * Move file to /sys/kernel/byteorder
> ---
> .../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: [email protected]
Why is this a filesystem thing? I don't see how that is true.
> +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 <[email protected]>
> */
>
> +#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.
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.
thanks,
greg k-h
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 <[email protected]>
> >
> > ---
> >
> > Development of userspace part: https://github.com/util-linux/util-linux/pull/1872
> >
> > v1: https://lore.kernel.org/lkml/[email protected]/
> > 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: [email protected]
>
> 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 <[email protected]>
> > */
> >
> > +#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