All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Al Stone <ahs3@redhat.com>
Cc: Timur Tabi <timur@codeaurora.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	lkml <linux-kernel@vger.kernel.org>,
	rruigrok@codeaurora.org, Jon Masters <jcm@redhat.com>
Subject: Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more human-readable
Date: Fri, 20 Oct 2017 17:10:53 +0100	[thread overview]
Message-ID: <20171020161053.ujw3spzizhgu4g7b@lakrids.cambridge.arm.com> (raw)
In-Reply-To: <abeb1756-3635-2f86-131c-cd904731a308@redhat.com>

Hi Al,

On Mon, Oct 16, 2017 at 05:43:19PM -0600, Al Stone wrote:
> On 10/13/2017 08:27 AM, Mark Rutland wrote:
> > I certainly agree that exposing the information that we have is useful,
> > as I have stated several times. I'm not NAKing exposing this information
> > elsewhere.
> > 
> > If you want a consistent cross-architecture interface for this
> > information, then you need to propose a new one. That was we can
> > actually solve the underlying issues, for all architectures, without
> > breaking ABI.
> > 
> > I would be *very* interested in such an interface, and would be more
> > than happy to help.
> 
> I'm playing with some patches that do very similar things in sysfs, vs
> proc.  Is that better :)?

Exposing data under sysfs is certainly better, yes. :)

> Obviously, you'll have to see the patches to
> properly answer that, but what I'm playing with at present is placing
> this info in new entries in /sys/devices/cpu and/or /sys/devices/system,
> and generating some of the content based on what's already in header files
> (e.g., in cputype.h). 

My opposition to MIDR -> string mapping applies regardless of
location...

> The idea of course is to keep this new info from touching any existing
> info so we don't break compatibility -- does that feel like a better
> direction, at least?

... but otherwise this sounds good to me!

Thanks,
Mark.

WARNING: multiple messages have this Message-ID (diff)
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more human-readable
Date: Fri, 20 Oct 2017 17:10:53 +0100	[thread overview]
Message-ID: <20171020161053.ujw3spzizhgu4g7b@lakrids.cambridge.arm.com> (raw)
In-Reply-To: <abeb1756-3635-2f86-131c-cd904731a308@redhat.com>

Hi Al,

On Mon, Oct 16, 2017 at 05:43:19PM -0600, Al Stone wrote:
> On 10/13/2017 08:27 AM, Mark Rutland wrote:
> > I certainly agree that exposing the information that we have is useful,
> > as I have stated several times. I'm not NAKing exposing this information
> > elsewhere.
> > 
> > If you want a consistent cross-architecture interface for this
> > information, then you need to propose a new one. That was we can
> > actually solve the underlying issues, for all architectures, without
> > breaking ABI.
> > 
> > I would be *very* interested in such an interface, and would be more
> > than happy to help.
> 
> I'm playing with some patches that do very similar things in sysfs, vs
> proc.  Is that better :)?

Exposing data under sysfs is certainly better, yes. :)

> Obviously, you'll have to see the patches to
> properly answer that, but what I'm playing with at present is placing
> this info in new entries in /sys/devices/cpu and/or /sys/devices/system,
> and generating some of the content based on what's already in header files
> (e.g., in cputype.h). 

My opposition to MIDR -> string mapping applies regardless of
location...

> The idea of course is to keep this new info from touching any existing
> info so we don't break compatibility -- does that feel like a better
> direction, at least?

... but otherwise this sounds good to me!

Thanks,
Mark.

  reply	other threads:[~2017-10-20 16:10 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-26 22:23 [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more human-readable Al Stone
2017-09-26 22:23 ` Al Stone
2017-09-26 22:23 ` [PATCH 1/3] arm64: cpuinfo: add MPIDR value to /proc/cpuinfo Al Stone
2017-09-26 22:23   ` Al Stone
2017-09-27 11:33   ` Mark Rutland
2017-09-27 11:33     ` Mark Rutland
2017-09-26 22:23 ` [PATCH 2/3] arm64: cpuinfo: add human readable CPU names " Al Stone
2017-09-26 22:23   ` Al Stone
2017-09-27 10:35   ` Robin Murphy
2017-09-27 10:35     ` Robin Murphy
2017-09-27 11:26   ` Mark Rutland
2017-09-27 11:26     ` Mark Rutland
2017-10-13 14:16   ` Timur Tabi
2017-10-13 14:16     ` Timur Tabi
2017-09-26 22:23 ` [PATCH 3/3] arm64: cpuinfo: display product info in /proc/cpuinfo Al Stone
2017-09-26 22:23   ` Al Stone
2017-09-27  0:40   ` Florian Fainelli
2017-09-27  0:40     ` Florian Fainelli
2017-09-27 10:42   ` Robin Murphy
2017-09-27 10:42     ` Robin Murphy
2017-09-27 13:39     ` Mark Rutland
2017-09-27 13:39       ` Mark Rutland
2017-09-27 11:36   ` Mark Rutland
2017-09-27 11:36     ` Mark Rutland
2017-10-13 19:27   ` Timur Tabi
2017-10-13 19:27     ` Timur Tabi
2017-09-27 10:34 ` [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more human-readable Mark Rutland
2017-09-27 10:34   ` Mark Rutland
2017-10-09 22:46   ` Al Stone
2017-10-09 22:46     ` Al Stone
2017-10-13 13:39   ` Timur Tabi
2017-10-13 13:39     ` Timur Tabi
2017-10-13 14:27     ` Mark Rutland
2017-10-13 14:27       ` Mark Rutland
2017-10-16 23:43       ` Al Stone
2017-10-16 23:43         ` Al Stone
2017-10-20 16:10         ` Mark Rutland [this message]
2017-10-20 16:10           ` Mark Rutland
2017-10-20 17:24           ` Jon Masters
2017-10-20 17:24             ` Jon Masters
2017-10-21  0:50             ` Jon Masters
2017-10-21  0:50               ` Jon Masters
2017-10-20 23:26           ` Al Stone
2017-10-20 23:26             ` Al Stone

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=20171020161053.ujw3spzizhgu4g7b@lakrids.cambridge.arm.com \
    --to=mark.rutland@arm.com \
    --cc=ahs3@redhat.com \
    --cc=jcm@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rruigrok@codeaurora.org \
    --cc=timur@codeaurora.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.