[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221205144525.2148448-1-conor.dooley@microchip.com>
Date: Mon, 5 Dec 2022 14:45:23 +0000
From: Conor Dooley <conor.dooley@...rochip.com>
To: <linux-riscv@...ts.infradead.org>,
Palmer Dabbelt <palmer@...belt.com>
CC: Conor Dooley <conor.dooley@...rochip.com>,
<ajones@...tanamicro.com>, <aou@...s.berkeley.edu>,
<conor@...nel.org>, <corbet@....net>, <guoren@...nel.org>,
<heiko@...ech.de>, <paul.walmsley@...ive.com>,
<linux-kernel@...r.kernel.org>, <linux-doc@...r.kernel.org>
Subject: [PATCH v2 0/3] Putting some basic order on isa extension lists
For v2+, I added another path with some uapi docs & switched to Drew's
suggested ordering of alphabetically, except in the /proc/cpuinfo array,
as per the discussion today in the pw-sync call. I also added a
sprinkling of comments around which things should be sorted in which
way.
Pasting from the chat on v2, since it's relevant to whether re-ordering
what appears in /proc/cpuinfo is even permitted..
I wrote:
> Drew wrote:
> > My biggest concern is how much we need to care about the order of the
> > string in proc and whether or not we're allowed to fix its order like
> > we're doing with this patch. I hope we can, and I vote we do.
>
> Being a bit hard-nosed about it:
> - the spec has said for years that this order is not correct
>
> - their parser cannot assume any given extension is even present, so the
> index at which the extension starts was only ever going to vary wildly
>
> - to break a parser, it must expect to see extension Abcd before Efgh &
> that order has to change for them
>
> - expecting that a given pair of extensions that appeared one after
> another would always do so is not something we should worry about
> breaking as it was always noted in the comment (and by the specs?)
> that new extensions would be added in alphabetical order (I'd like to
> think that if a clairvoyant wrote a parser and knew that there'd be
> nothing in the gap between the extensions we have now & what may be
> produced they'd also account for this re-ordering...)
>
> - the re-order of sstc is going to land for v6.1 & the addition of sstc
> out of order landed in v6.0, so either that is an issue too or this is
> fine
I'm sending the patchset, so I think it's bordering on obvious that I
think doing this is likely okay & maintaining a "strict" interpretation
of what the spec says is the way to go.
I think the only case we have to worry about breaking uABI stuff is if
this changes behaviour in a way that could not be done by an otherwise
valid change in the ISA string, so bullet 3 above.
I'll leave that determination up to the Higher Powers, but I think it's
going to be very difficult not to accidentally break this order in the
future if we decide that what is currently there, must remain exactly
as-is.
Thanks,
Conor.
Changes since v1:
- strengthened some wording to use "must"
- reworded the bits in both code & doc about what canonical order is
- added some missing "... must be in alphabetical order" sections to
both code & doc
- forced an _ before multi-letter extensions
- there's likely a trivial conflict with drew's addition of an assert
for RISCV_ISA_EXT_ID_MAX.
CC: ajones@...tanamicro.com
CC: aou@...s.berkeley.edu
CC: conor@...nel.org
CC: conor.dooley@...rochip.com
CC: corbet@....net
CC: guoren@...nel.org
CC: heiko@...ech.de
CC: palmer@...belt.com
CC: paul.walmsley@...ive.com
CC: linux-kernel@...r.kernel.org
CC: linux-riscv@...ts.infradead.org
CC: linux-doc@...r.kernel.org
Conor Dooley (3):
RISC-V: clarify ISA string ordering rules in cpu.c
RISC-V: resort all extensions in consistent orders
Documentation: riscv: add a section about ISA string ordering in
/proc/cpuinfo
Documentation/riscv/uabi.rst | 42 +++++++++++++++++++++++++++
arch/riscv/include/asm/hwcap.h | 12 ++++----
arch/riscv/kernel/cpu.c | 53 ++++++++++++++++++++++++----------
arch/riscv/kernel/cpufeature.c | 6 ++--
4 files changed, 91 insertions(+), 22 deletions(-)
--
2.38.1
Powered by blists - more mailing lists