On Thu, Mar 10, 2022 at 3:50 PM Palmer Dabbelt <palmer@xxxxxxxxxxx> wrote:
On Tue, 22 Feb 2022 12:48:05 PST (-0800), Atish Patra wrote:
> This series implements a generic framework to parse multi-letter ISA
> extensions. This series is based on Tsukasa's v3 isa extension improvement
> series[1]. I have fixed few bugs and improved comments from that series
> (PATCH1-3). I have not used PATCH 4 from that series as we are not using
> ISA extension versioning as of now. We can add that later if required.
>
> PATCH 4 allows the probing of multi-letter extensions via a macro.
> It continues to use the common isa extensions between all the harts.
> Thus hetergenous hart systems will only see the common ISA extensions.
>
> PATCH 6 improves the /proc/cpuinfo interface for the available ISA extensions
> via /proc/cpuinfo.
>
> Here is the example output of /proc/cpuinfo:
> (with debug patches in Qemu and Linux kernel)
>
> # cat /proc/cpuinfo
> processor : 0
> hart : 0
> isa : rv64imafdch
> isa-ext : svpbmt svnapot svinval
I know it might seem a bit pedantic, but I really don't want to
introduce a new format for encoding ISA extensions -- doubly so if this
is the only way we're giving this info to userspace, as then we're just
asking folks to turn this into a defacto ABI. Every time we try to do
something that's sort of like an ISA string but not exactly what's in
the spec we end up getting burned, and while I don't see a specific way
I agree that this is an ABI change/improvement which is impossible to
modify later.
However, this is a Linux specific ABI. Do you think the RISC-V spec
will ever say anything about how /proc/cpuinfo is shown to the user ?