All of lore.kernel.org
 help / color / mirror / Atom feed
From: Conor Dooley <conor@kernel.org>
To: Palmer Dabbelt <palmer@dabbelt.com>, linux-riscv@lists.infradead.org
Cc: Conor Dooley <conor.dooley@microchip.com>,
	ajones@ventanamicro.com, aou@eecs.berkeley.edu, conor@kernel.org,
	corbet@lwn.net, guoren@kernel.org, heiko@sntech.de,
	paul.walmsley@sifive.com, linux-kernel@vger.kernel.org,
	linux-doc@vger.kernel.org
Subject: [PATCH v1 3/3] Documentation: riscv: add a section about ISA string ordering in /proc/cpuinfo
Date: Wed, 30 Nov 2022 23:41:26 +0000	[thread overview]
Message-ID: <20221130234125.2722364-4-conor@kernel.org> (raw)
In-Reply-To: <20221130234125.2722364-1-conor@kernel.org>

From: Conor Dooley <conor.dooley@microchip.com>

The RISC-V specs are permissive in what they allow as the ISA string,
but how we output this to userspace in /proc/cpuinfo is quasi uAPI.

Formalise this as part of the uAPI, by documenting the list of rules
we use at this point in time.

Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
I've not "tested" these docs. The NIPA-esque pwbot should go and
test it AFAICT. If it doesn't, I'll go add that.
---
 Documentation/riscv/uabi.rst | 42 ++++++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/Documentation/riscv/uabi.rst b/Documentation/riscv/uabi.rst
index 21a82cfb6c4d..bc3c8ced644b 100644
--- a/Documentation/riscv/uabi.rst
+++ b/Documentation/riscv/uabi.rst
@@ -3,4 +3,46 @@
 RISC-V Linux User ABI
 =====================
 
+Misaligned accesses
+-------------------
+
 Misaligned accesses are supported in userspace, but they may perform poorly.
+
+ISA string ordering in /proc/cpuinfo
+------------------------------------
+
+The canonical order of ISA extension names in the ISA string is defined in
+chapter 27 of the unprivileged specification.
+The specification uses vague wording, such as should, when it comes to
+ordering, so for our purposes the following rules apply:
+
+#. Single-letter extensions come first, in "canonical order", so
+   "IMAFDQLCBKJTPVH".
+
+#. All multi-letter extensions will be separated from other multi-letter
+   extensions by an underscore.
+
+#. Additional standard extensions (starting with 'Z') will be sorted after
+   single-letter extensions and before any higher-privileged extensions.
+
+#. The first letter following the 'Z' conventionally indicates the most
+   closely related alphabetical extension category, IMAFDQLCBKJTPVH.
+   If multiple 'Z' extensions are named, they should be ordered first by
+   category, then alphabetically within a category.
+
+#. Standard supervisor-level extensions (starting with 'S') will be listed
+   after standard unprivileged extensions.  If multiple
+   supervisor-level extensions are listed, they will be ordered
+   alphabetically.
+
+#. Standard machine-level extensions (starting with 'Zxm') will be listed
+   after any lower-privileged, standard extensions.  If multiple
+   machine-level extensions are listed, they will be ordered
+   alphabetically.
+
+#. Non-standard extensions (starts with 'X') will be listed after all
+   standard extensions.
+
+An example string following the order is:
+   rv64imadc_zifoo_zigoo_zafoo_sbar_scar_zxmbaz_xqux_xrux
+
-- 
2.38.1


WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor@kernel.org>
To: Palmer Dabbelt <palmer@dabbelt.com>, linux-riscv@lists.infradead.org
Cc: Conor Dooley <conor.dooley@microchip.com>,
	ajones@ventanamicro.com, aou@eecs.berkeley.edu, conor@kernel.org,
	corbet@lwn.net, guoren@kernel.org, heiko@sntech.de,
	paul.walmsley@sifive.com, linux-kernel@vger.kernel.org,
	linux-doc@vger.kernel.org
Subject: [PATCH v1 3/3] Documentation: riscv: add a section about ISA string ordering in /proc/cpuinfo
Date: Wed, 30 Nov 2022 23:41:26 +0000	[thread overview]
Message-ID: <20221130234125.2722364-4-conor@kernel.org> (raw)
In-Reply-To: <20221130234125.2722364-1-conor@kernel.org>

From: Conor Dooley <conor.dooley@microchip.com>

The RISC-V specs are permissive in what they allow as the ISA string,
but how we output this to userspace in /proc/cpuinfo is quasi uAPI.

Formalise this as part of the uAPI, by documenting the list of rules
we use at this point in time.

Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
I've not "tested" these docs. The NIPA-esque pwbot should go and
test it AFAICT. If it doesn't, I'll go add that.
---
 Documentation/riscv/uabi.rst | 42 ++++++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/Documentation/riscv/uabi.rst b/Documentation/riscv/uabi.rst
index 21a82cfb6c4d..bc3c8ced644b 100644
--- a/Documentation/riscv/uabi.rst
+++ b/Documentation/riscv/uabi.rst
@@ -3,4 +3,46 @@
 RISC-V Linux User ABI
 =====================
 
+Misaligned accesses
+-------------------
+
 Misaligned accesses are supported in userspace, but they may perform poorly.
+
+ISA string ordering in /proc/cpuinfo
+------------------------------------
+
+The canonical order of ISA extension names in the ISA string is defined in
+chapter 27 of the unprivileged specification.
+The specification uses vague wording, such as should, when it comes to
+ordering, so for our purposes the following rules apply:
+
+#. Single-letter extensions come first, in "canonical order", so
+   "IMAFDQLCBKJTPVH".
+
+#. All multi-letter extensions will be separated from other multi-letter
+   extensions by an underscore.
+
+#. Additional standard extensions (starting with 'Z') will be sorted after
+   single-letter extensions and before any higher-privileged extensions.
+
+#. The first letter following the 'Z' conventionally indicates the most
+   closely related alphabetical extension category, IMAFDQLCBKJTPVH.
+   If multiple 'Z' extensions are named, they should be ordered first by
+   category, then alphabetically within a category.
+
+#. Standard supervisor-level extensions (starting with 'S') will be listed
+   after standard unprivileged extensions.  If multiple
+   supervisor-level extensions are listed, they will be ordered
+   alphabetically.
+
+#. Standard machine-level extensions (starting with 'Zxm') will be listed
+   after any lower-privileged, standard extensions.  If multiple
+   machine-level extensions are listed, they will be ordered
+   alphabetically.
+
+#. Non-standard extensions (starts with 'X') will be listed after all
+   standard extensions.
+
+An example string following the order is:
+   rv64imadc_zifoo_zigoo_zafoo_sbar_scar_zxmbaz_xqux_xrux
+
-- 
2.38.1


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  parent reply	other threads:[~2022-11-30 23:42 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-30 23:41 [PATCH v1 0/3] Putting some basic order on isa extension lists Conor Dooley
2022-11-30 23:41 ` Conor Dooley
2022-11-30 23:41 ` [PATCH v1 1/3] RISC-V: clarify ISA string ordering rules in cpu.c Conor Dooley
2022-11-30 23:41   ` Conor Dooley
2022-12-01  8:27   ` Andrew Jones
2022-12-01  8:27     ` Andrew Jones
2022-12-01  8:48     ` Conor Dooley
2022-12-01  8:48       ` Conor Dooley
2022-11-30 23:41 ` [PATCH v1 2/3] RISC-V: resort all extensions in consistent orders Conor Dooley
2022-11-30 23:41   ` Conor Dooley
2022-12-01  9:00   ` Andrew Jones
2022-12-01  9:00     ` Andrew Jones
2022-12-01 10:47     ` Heiko Stübner
2022-12-01 10:47       ` Heiko Stübner
2022-12-01 11:38       ` Andrew Jones
2022-12-01 11:38         ` Andrew Jones
2022-12-01 12:29     ` Conor Dooley
2022-12-01 12:29       ` Conor Dooley
2022-12-01 12:37       ` Conor.Dooley
2022-12-01 12:37         ` Conor.Dooley
2022-12-01 10:48   ` Heiko Stübner
2022-12-01 10:48     ` Heiko Stübner
2022-11-30 23:41 ` Conor Dooley [this message]
2022-11-30 23:41   ` [PATCH v1 3/3] Documentation: riscv: add a section about ISA string ordering in /proc/cpuinfo Conor Dooley
2022-11-30 23:46   ` Conor Dooley
2022-11-30 23:46     ` Conor Dooley
2022-12-01  3:05   ` Bagas Sanjaya
2022-12-01  3:05     ` Bagas Sanjaya
2022-12-01  8:17     ` Conor Dooley
2022-12-01  8:17       ` Conor Dooley
2022-12-02  2:14       ` Bagas Sanjaya
2022-12-02  2:14         ` Bagas Sanjaya
2022-12-02 11:37         ` Conor Dooley
2022-12-02 11:37           ` Conor Dooley
2022-12-01  9:14   ` Andrew Jones
2022-12-01  9:14     ` Andrew Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221130234125.2722364-4-conor@kernel.org \
    --to=conor@kernel.org \
    --cc=ajones@ventanamicro.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=conor.dooley@microchip.com \
    --cc=corbet@lwn.net \
    --cc=guoren@kernel.org \
    --cc=heiko@sntech.de \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.