lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y8qiUCH6ERYmAdgg@wendy>
Date:   Fri, 20 Jan 2023 14:16:48 +0000
From:   Conor Dooley <conor.dooley@...rochip.com>
To:     Andrew Jones <ajones@...tanamicro.com>
CC:     <linux-riscv@...ts.infradead.org>,
        Palmer Dabbelt <palmer@...belt.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>,
        Heiko Stuebner <heiko.stuebner@...ll.eu>
Subject: Re: [PATCH v2 2/3] RISC-V: resort all extensions in consistent orders

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.


Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ