All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	David Sterba <dsterba@suse.com>
Subject: Re: [PATCH 1/1] drivers/base/cpu: Print kernel arch
Date: Thu, 28 Jul 2022 09:35:11 +0200	[thread overview]
Message-ID: <YuI8L3xgAIlwBVFU@pevik> (raw)
In-Reply-To: <YuIz5bvMLKQeYn1h@kroah.com>

> 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 <pvorel@suse.cz>
> > > > ---
> > > >  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

      reply	other threads:[~2022-07-28  7:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-27 16:11 [PATCH 1/1] drivers/base/cpu: Print kernel arch Petr Vorel
2022-07-27 16:40 ` Greg Kroah-Hartman
2022-07-27 22:22   ` Petr Vorel
2022-07-28  6:59     ` Greg Kroah-Hartman
2022-07-28  7:35       ` Petr Vorel [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YuI8L3xgAIlwBVFU@pevik \
    --to=pvorel@suse.cz \
    --cc=dsterba@suse.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.