[PATCH v2 2/3] RISC-V: resort all extensions in consistent orders
Conor Dooley
conor.dooley at microchip.com
Fri Jan 20 06:16:48 PST 2023
On Fri, Jan 20, 2023 at 02:56:32PM +0100, Andrew Jones wrote:
> Hi Conor,
>
> I'm digging this back up because I'm basing Zicboz on it.
>
> If we take "riscv: improve boot time isa extensions handling", then this
> becomes a bunch of manually enumerated defines
>
> #define RISCV_ISA_EXT_SSCOFPMF 26
> #define RISCV_ISA_EXT_SVPBMT 27
> #define RISCV_ISA_EXT_ZICBOM 28
> #define RISCV_ISA_EXT_ZIHINTPAUSE 29
> #define RISCV_ISA_EXT_SSTC 30
> #define RISCV_ISA_EXT_SVINVAL 31
>
> Keeping those in alphabetical order would either require manually
> reenumerating them or to allow the numbers to be out of order as
> we add more extensions. I think I'd prefer we just add new
> extensions at the bottom and keep the numbers in order.
Yes. I mentioned that on one of the earlier versions of Jisheng's
patchset - initially I blindly said "alphabetical please".
I quickly realised that that was a really stupid idea as it is would
just be an _invitiation_ for bugs if we did, since names are far more
easily searchable than figuring out the max in the manual enumeration.
Since Jisheng's patchset just deleted what I had resorted, I left this
change as-was. Just need to make sure any comment about ordering also
gets removed when the enum goes away.
I'll keep an eye on for-next to make sure that it does.
TL;DR I agree!
Thanks,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20230120/6beeb936/attachment.sig>
More information about the linux-riscv
mailing list