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@xxxxxxxxxxxxxxxx
CC: aou@xxxxxxxxxxxxxxxxx
CC: conor@xxxxxxxxxx
CC: conor.dooley@xxxxxxxxxxxxx
CC: corbet@xxxxxxx
CC: guoren@xxxxxxxxxx
CC: heiko@xxxxxxxxx
CC: palmer@xxxxxxxxxxx
CC: paul.walmsley@xxxxxxxxxx
CC: linux-kernel@xxxxxxxxxxxxxxx
CC: linux-riscv@xxxxxxxxxxxxxxxxxxx
CC: linux-doc@xxxxxxxxxxxxxxx
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
