All of lore.kernel.org
 help / color / mirror / Atom feed
From: marcus.shawcroft@arm.com (Marcus Shawcroft)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv4 5/5] arm64: cpuinfo: print info for all CPUs
Date: Thu, 17 Jul 2014 11:46:24 +0100	[thread overview]
Message-ID: <53C7A980.8050601@arm.com> (raw)
In-Reply-To: <CAFEAcA-_GawEimGS4q8=C7BK6gLzSA+xVSUtLFkUS5=Mf8syBw@mail.gmail.com>

On 17/07/14 11:39, Peter Maydell wrote:
> On 16 July 2014 16:57, Will Deacon <will.deacon@arm.com> wrote:
>> I don't have hugely strong opinions about this, but I don't see why it's
>> useful to print exactly the same line out `n' times; once for each CPU. We
>> only pass one set of hwcaps to ELF executables via auxv, so why do we need
>> to duplicate things here?
>
> I think there are a couple of lines of argument here:
>
> (1) Precedent from other architectures. Both 32-bit ARM and
> x86 have the feature-info be per-core; we should do the same
> for 64-bit ARM unless there's a really strong reason not to.

Agreed.

> (2) Making this be not-per-CPU backs us into a corner. If we
> have the feature flags per-core, and it turns out that they're
> never ever different between cores even on heterogenous
> CPUs, there's no problem. If we have the feature flags be
> listed only once, and then in future we do want to support
> some minor form of heterogeny between cores, then we're
> stuck with a compatibility break because the format doesn't
> let us express that. (Perhaps there might be a big.LITTLE
> system where only the big cores had the crypto extensions,
> to pick a random possibility where the kernel doesn't need to
> care but userspace could take advantage by restricting itself
> to running on only the big cores). I think this makes the
> choice pretty straightforward, since there's basically no
> benefit to having only a single features line.

Agreed.

This patch is in itself an ABI break for anyone consuming /proc/cpuinfo. 
  Making this be not-per-cpu just sets us up for another ABI break in 
the future, not ideal.

Cheers
/Marcus

  reply	other threads:[~2014-07-17 10:46 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-16 15:32 [PATCHv4 0/5] arm64: handle heterogeneous system register values Mark Rutland
2014-07-16 15:32 ` [PATCHv4 1/5] arm64: add MIDR_EL1 field accessors Mark Rutland
2014-07-16 15:32 ` [PATCHv4 2/5] arm64: cpuinfo: record cpu system register values Mark Rutland
2014-07-16 15:32 ` [PATCHv4 3/5] arm64: cachetype: report weakest cache policy Mark Rutland
2014-07-16 15:32 ` [PATCHv4 4/5] arm64: add runtime system sanity checks Mark Rutland
2014-07-16 15:32 ` [PATCHv4 5/5] arm64: cpuinfo: print info for all CPUs Mark Rutland
2014-07-16 15:57   ` Will Deacon
2014-07-17 10:30     ` Catalin Marinas
2014-07-17 10:39     ` Peter Maydell
2014-07-17 10:46       ` Marcus Shawcroft [this message]
2014-07-17 10:54         ` Will Deacon
2014-07-17 11:09           ` Ard Biesheuvel
2014-07-17 11:12           ` Peter Maydell
2014-07-17 12:35             ` Will Deacon
2014-07-17 13:55               ` Peter Maydell
2014-07-17 17:10                 ` Catalin Marinas
2014-07-17 17:28                   ` Will Deacon
2014-07-18  9:27                     ` Catalin Marinas
2014-07-18  9:53                       ` Will Deacon
2014-07-18 13:57                         ` Mark Rutland
2014-07-18 15:52                           ` Peter Maydell
2014-07-18 15:58                             ` Mark Rutland
2014-07-18 16:18                               ` Peter Maydell
2014-07-18 16:41                                 ` Mark Rutland
2014-07-18 20:24                                   ` Christopher Covington
2014-07-16 15:55 ` [PATCHv4 0/5] arm64: handle heterogeneous system register values Will Deacon
2014-07-17 11:03 ` Catalin Marinas
2014-07-17 14:21   ` Mark Rutland
2014-07-17 14:28     ` Will Deacon

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=53C7A980.8050601@arm.com \
    --to=marcus.shawcroft@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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.