All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Al Stone <ahs3@redhat.com>
Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more human-readable
Date: Wed, 27 Sep 2017 11:34:07 +0100	[thread overview]
Message-ID: <20170927103406.GC32150@leverpostej> (raw)
In-Reply-To: <20170926222324.17409-1-ahs3@redhat.com>

Hi Al,

On Tue, Sep 26, 2017 at 04:23:21PM -0600, Al Stone wrote:
> As ARMv8 servers get deployed, I keep getting the same set of questions
> from end-users of those systems: what do all the hex numbers mean in 
> /proc/cpuinfo and could you make them so I don't have to carry a cheat
> sheet with me all the time?

I appreciate that /proc/cpuinfo can be opaque to end users, but I do not
believe that this is the right solution to that problem.

There are a number of issues stemming from the face that /proc/cpuinfo
is ill-defined and overused for a number of cases. Changes to it almost
certainly violate brittle de-facto ABI details people are relying on,
and there's a very long tail on fallout resulting from this. In
addition, many niceties come at an excessive maintenance cost, and are
simply unreliable as an ABI.

So, as with all other patches modifying /proc/cpuinfo, I must NAK this
series.

For the MPIDR and product info, I think we can expose this in a more
structured way (e.g. under sysfs). IIUC the product info is all derived
from DMI -- do we not expose that already?

For the human-readable names I must NAK such patches. This is an
extremely brittle ABI that cannot be forwards compatible, and comes with
hilarious political problems. This should be managed in userspace alone.

I thought tools like lscpu and lshw were intended to gather such
information for users. What are these missing today?

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: Wed, 27 Sep 2017 11:34:07 +0100	[thread overview]
Message-ID: <20170927103406.GC32150@leverpostej> (raw)
In-Reply-To: <20170926222324.17409-1-ahs3@redhat.com>

Hi Al,

On Tue, Sep 26, 2017 at 04:23:21PM -0600, Al Stone wrote:
> As ARMv8 servers get deployed, I keep getting the same set of questions
> from end-users of those systems: what do all the hex numbers mean in 
> /proc/cpuinfo and could you make them so I don't have to carry a cheat
> sheet with me all the time?

I appreciate that /proc/cpuinfo can be opaque to end users, but I do not
believe that this is the right solution to that problem.

There are a number of issues stemming from the face that /proc/cpuinfo
is ill-defined and overused for a number of cases. Changes to it almost
certainly violate brittle de-facto ABI details people are relying on,
and there's a very long tail on fallout resulting from this. In
addition, many niceties come at an excessive maintenance cost, and are
simply unreliable as an ABI.

So, as with all other patches modifying /proc/cpuinfo, I must NAK this
series.

For the MPIDR and product info, I think we can expose this in a more
structured way (e.g. under sysfs). IIUC the product info is all derived
from DMI -- do we not expose that already?

For the human-readable names I must NAK such patches. This is an
extremely brittle ABI that cannot be forwards compatible, and comes with
hilarious political problems. This should be managed in userspace alone.

I thought tools like lscpu and lshw were intended to gather such
information for users. What are these missing today?

Thanks,
Mark.

  parent reply	other threads:[~2017-09-27 10:35 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 ` Mark Rutland [this message]
2017-09-27 10:34   ` [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more human-readable 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
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=20170927103406.GC32150@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=ahs3@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.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.