Print kernel architecture in /sys/devices/system/cpu/arch
using UTS_MACHINE, i.e. member of struct uts_namespace.machine.
This helps people who debug kernel with initramfs with minimal
environment (i.e. without coreutils or even busybox) or allow to open
sysfs file instead of run uname -m in high level languages.
Signed-off-by: Petr Vorel <[email protected]>
---
drivers/base/cpu.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index 4c98849577d4..7c8032e3ff10 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -3,6 +3,7 @@
* CPU subsystem support
*/
+#include <generated/compile.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>
@@ -232,6 +233,13 @@ static ssize_t print_cpus_kernel_max(struct device *dev,
}
static DEVICE_ATTR(kernel_max, 0444, print_cpus_kernel_max, NULL);
+static ssize_t print_cpus_arch(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return sysfs_emit(buf, "%s\n", UTS_MACHINE);
+}
+static DEVICE_ATTR(arch, 0444, print_cpus_arch, NULL);
+
/* arch-optional setting to enable display of offline cpus >= nr_cpu_ids */
unsigned int total_cpus;
@@ -464,6 +472,7 @@ static struct attribute *cpu_root_attrs[] = {
&cpu_attrs[1].attr.attr,
&cpu_attrs[2].attr.attr,
&dev_attr_kernel_max.attr,
+ &dev_attr_arch.attr,
&dev_attr_offline.attr,
&dev_attr_isolated.attr,
#ifdef CONFIG_NO_HZ_FULL
--
2.37.1
On Wed, Jul 27, 2022 at 06:11:35PM +0200, Petr Vorel wrote:
> Print kernel architecture in /sys/devices/system/cpu/arch
> using UTS_MACHINE, i.e. member of struct uts_namespace.machine.
>
> This helps people who debug kernel with initramfs with minimal
> environment (i.e. without coreutils or even busybox) or allow to open
> sysfs file instead of run uname -m in high level languages.
>
> Signed-off-by: Petr Vorel <[email protected]>
> ---
> drivers/base/cpu.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
You can't add a new sysfs file without a Documentation/ABI/ update as
well. Please fix that up.
>
> diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
> index 4c98849577d4..7c8032e3ff10 100644
> --- a/drivers/base/cpu.c
> +++ b/drivers/base/cpu.c
> @@ -3,6 +3,7 @@
> * CPU subsystem support
> */
>
> +#include <generated/compile.h>
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <linux/init.h>
> @@ -232,6 +233,13 @@ static ssize_t print_cpus_kernel_max(struct device *dev,
> }
> static DEVICE_ATTR(kernel_max, 0444, print_cpus_kernel_max, NULL);
>
> +static ssize_t print_cpus_arch(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + return sysfs_emit(buf, "%s\n", UTS_MACHINE);
> +}
> +static DEVICE_ATTR(arch, 0444, print_cpus_arch, NULL);
why just UTS_MACHINE? Doesn't 'uname' show this already? And I thought
this was in /proc/cpuinfo but odd, it isn't...
Also what about the other things in compile.h?
thanks,
greg k-h
Hi Greg,
thanks for your review!
> On Wed, Jul 27, 2022 at 06:11:35PM +0200, Petr Vorel wrote:
> > Print kernel architecture in /sys/devices/system/cpu/arch
> > using UTS_MACHINE, i.e. member of struct uts_namespace.machine.
> > This helps people who debug kernel with initramfs with minimal
> > environment (i.e. without coreutils or even busybox) or allow to open
> > sysfs file instead of run uname -m in high level languages.
> > Signed-off-by: Petr Vorel <[email protected]>
> > ---
> > drivers/base/cpu.c | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> You can't add a new sysfs file without a Documentation/ABI/ update as
> well. Please fix that up.
I'm sorry. Yes, I realized it later on (once I got offline).
Sure, I'll fix this in v2. But the main question is whether this feature is
acceptable and what is the best place for the file.
> > diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
> > index 4c98849577d4..7c8032e3ff10 100644
> > --- a/drivers/base/cpu.c
> > +++ b/drivers/base/cpu.c
> > @@ -3,6 +3,7 @@
> > * CPU subsystem support
> > */
> > +#include <generated/compile.h>
> > #include <linux/kernel.h>
> > #include <linux/module.h>
> > #include <linux/init.h>
> > @@ -232,6 +233,13 @@ static ssize_t print_cpus_kernel_max(struct device *dev,
> > }
> > static DEVICE_ATTR(kernel_max, 0444, print_cpus_kernel_max, NULL);
> > +static ssize_t print_cpus_arch(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > + return sysfs_emit(buf, "%s\n", UTS_MACHINE);
> > +}
> > +static DEVICE_ATTR(arch, 0444, print_cpus_arch, NULL);
> why just UTS_MACHINE? Doesn't 'uname' show this already? And I thought
> this was in /proc/cpuinfo but odd, it isn't...
Sure, this info is in uname(). But for certain cases is really easier to read
file from /proc or /sys than run create custom C bindings or a binary which
calls uname(2) libc wrapper or run uname binary via execve(2).
Yes, I also expected /proc/cpuinfo would have it but it does not have it. I
don't think it's a good idea to add 'arch : foo' line to it, but I can do if
there is consensus that it's the best place.
> Also what about the other things in compile.h?
UTS_VERSION is in /proc/version.
LINUX_COMPILE_BY (e.g. "user"), LINUX_COMPILE_HOST (e.g. "host") and
LINUX_COMPILER (e.g. "aarch64-alpine-linux-musl-gcc (Alpine 11.2.1_git20220219)
...") are IMHO useless, but I can add it if you wish.
Well, there is hostname in /proc/sys/kernel/hostname, there are also ostype and
osrelease.. Thinking about it twice /proc/sys/kernel/ looks to me a better place
for arch file than current /sys/devices/system/cpu/. WDYT?
Kind regards,
Petr
> thanks,
> greg k-h
On Thu, Jul 28, 2022 at 12:22:05AM +0200, Petr Vorel wrote:
> Hi Greg,
>
> thanks for your review!
>
> > On Wed, Jul 27, 2022 at 06:11:35PM +0200, Petr Vorel wrote:
> > > Print kernel architecture in /sys/devices/system/cpu/arch
> > > using UTS_MACHINE, i.e. member of struct uts_namespace.machine.
>
> > > This helps people who debug kernel with initramfs with minimal
> > > environment (i.e. without coreutils or even busybox) or allow to open
> > > sysfs file instead of run uname -m in high level languages.
>
> > > Signed-off-by: Petr Vorel <[email protected]>
> > > ---
> > > drivers/base/cpu.c | 9 +++++++++
> > > 1 file changed, 9 insertions(+)
>
> > You can't add a new sysfs file without a Documentation/ABI/ update as
> > well. Please fix that up.
> I'm sorry. Yes, I realized it later on (once I got offline).
> Sure, I'll fix this in v2. But the main question is whether this feature is
> acceptable and what is the best place for the file.
>
>
> > > diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
> > > index 4c98849577d4..7c8032e3ff10 100644
> > > --- a/drivers/base/cpu.c
> > > +++ b/drivers/base/cpu.c
> > > @@ -3,6 +3,7 @@
> > > * CPU subsystem support
> > > */
>
> > > +#include <generated/compile.h>
> > > #include <linux/kernel.h>
> > > #include <linux/module.h>
> > > #include <linux/init.h>
> > > @@ -232,6 +233,13 @@ static ssize_t print_cpus_kernel_max(struct device *dev,
> > > }
> > > static DEVICE_ATTR(kernel_max, 0444, print_cpus_kernel_max, NULL);
>
> > > +static ssize_t print_cpus_arch(struct device *dev,
> > > + struct device_attribute *attr, char *buf)
> > > +{
> > > + return sysfs_emit(buf, "%s\n", UTS_MACHINE);
> > > +}
> > > +static DEVICE_ATTR(arch, 0444, print_cpus_arch, NULL);
>
> > why just UTS_MACHINE? Doesn't 'uname' show this already? And I thought
> > this was in /proc/cpuinfo but odd, it isn't...
> Sure, this info is in uname(). But for certain cases is really easier to read
> file from /proc or /sys than run create custom C bindings or a binary which
> calls uname(2) libc wrapper or run uname binary via execve(2).
>
> Yes, I also expected /proc/cpuinfo would have it but it does not have it. I
> don't think it's a good idea to add 'arch : foo' line to it, but I can do if
> there is consensus that it's the best place.
>
> > Also what about the other things in compile.h?
> UTS_VERSION is in /proc/version.
> LINUX_COMPILE_BY (e.g. "user"), LINUX_COMPILE_HOST (e.g. "host") and
> LINUX_COMPILER (e.g. "aarch64-alpine-linux-musl-gcc (Alpine 11.2.1_git20220219)
> ...") are IMHO useless, but I can add it if you wish.
>
> Well, there is hostname in /proc/sys/kernel/hostname, there are also ostype and
> osrelease.. Thinking about it twice /proc/sys/kernel/ looks to me a better place
> for arch file than current /sys/devices/system/cpu/. WDYT?
Yeah, I think /proc/sys/kernel/ makes sense, good idea.
greg k-h
> On Thu, Jul 28, 2022 at 12:22:05AM +0200, Petr Vorel wrote:
> > Hi Greg,
> > thanks for your review!
> > > On Wed, Jul 27, 2022 at 06:11:35PM +0200, Petr Vorel wrote:
> > > > Print kernel architecture in /sys/devices/system/cpu/arch
> > > > using UTS_MACHINE, i.e. member of struct uts_namespace.machine.
> > > > This helps people who debug kernel with initramfs with minimal
> > > > environment (i.e. without coreutils or even busybox) or allow to open
> > > > sysfs file instead of run uname -m in high level languages.
> > > > Signed-off-by: Petr Vorel <[email protected]>
> > > > ---
> > > > drivers/base/cpu.c | 9 +++++++++
> > > > 1 file changed, 9 insertions(+)
> > > You can't add a new sysfs file without a Documentation/ABI/ update as
> > > well. Please fix that up.
> > I'm sorry. Yes, I realized it later on (once I got offline).
> > Sure, I'll fix this in v2. But the main question is whether this feature is
> > acceptable and what is the best place for the file.
> > > > diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
> > > > index 4c98849577d4..7c8032e3ff10 100644
> > > > --- a/drivers/base/cpu.c
> > > > +++ b/drivers/base/cpu.c
> > > > @@ -3,6 +3,7 @@
> > > > * CPU subsystem support
> > > > */
> > > > +#include <generated/compile.h>
> > > > #include <linux/kernel.h>
> > > > #include <linux/module.h>
> > > > #include <linux/init.h>
> > > > @@ -232,6 +233,13 @@ static ssize_t print_cpus_kernel_max(struct device *dev,
> > > > }
> > > > static DEVICE_ATTR(kernel_max, 0444, print_cpus_kernel_max, NULL);
> > > > +static ssize_t print_cpus_arch(struct device *dev,
> > > > + struct device_attribute *attr, char *buf)
> > > > +{
> > > > + return sysfs_emit(buf, "%s\n", UTS_MACHINE);
> > > > +}
> > > > +static DEVICE_ATTR(arch, 0444, print_cpus_arch, NULL);
> > > why just UTS_MACHINE? Doesn't 'uname' show this already? And I thought
> > > this was in /proc/cpuinfo but odd, it isn't...
> > Sure, this info is in uname(). But for certain cases is really easier to read
> > file from /proc or /sys than run create custom C bindings or a binary which
> > calls uname(2) libc wrapper or run uname binary via execve(2).
> > Yes, I also expected /proc/cpuinfo would have it but it does not have it. I
> > don't think it's a good idea to add 'arch : foo' line to it, but I can do if
> > there is consensus that it's the best place.
> > > Also what about the other things in compile.h?
> > UTS_VERSION is in /proc/version.
> > LINUX_COMPILE_BY (e.g. "user"), LINUX_COMPILE_HOST (e.g. "host") and
> > LINUX_COMPILER (e.g. "aarch64-alpine-linux-musl-gcc (Alpine 11.2.1_git20220219)
> > ...") are IMHO useless, but I can add it if you wish.
> > Well, there is hostname in /proc/sys/kernel/hostname, there are also ostype and
> > osrelease.. Thinking about it twice /proc/sys/kernel/ looks to me a better place
> > for arch file than current /sys/devices/system/cpu/. WDYT?
> Yeah, I think /proc/sys/kernel/ makes sense, good idea.
Thanks for info, I'll send v2 shortly.
Kind regards,
Petr
> greg k-h