From: "Björn Töpel" <bjorn@kernel.org>
To: Jessica Clarke <jrtc27@jrtc27.com>
Cc: Heiko Stuebner <heiko@sntech.de>,
Palmer Dabbelt <palmer@dabbelt.com>,
linux-riscv <linux-riscv@lists.infradead.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
Kito Cheng <kito.cheng@sifive.com>,
Conor Dooley <conor.dooley@microchip.com>,
matthias.bgg@gmail.com,
Heinrich Schuchardt <heinrich.schuchardt@canonical.com>,
Greentime Hu <greentime.hu@sifive.com>,
nick.knight@sifive.com, christoph.muellner@vrull.eu,
philipp.tomsich@vrull.eu, richard.henderson@linaro.org,
arnd@arndb.de, linux-kernel@vger.kernel.org,
Heiko Stuebner <heiko.stuebner@vrull.eu>
Subject: Re: [PATCH 0/4] Expose the isa-string via the AT_BASE_PLATFORM aux vector
Date: Tue, 02 May 2023 07:48:10 +0200 [thread overview]
Message-ID: <878re77085.fsf@all.your.base.are.belong.to.us> (raw)
In-Reply-To: <7DD2C38C-CBB3-41EE-A195-50E4C2451B7E@jrtc27.com>
Jessica Clarke <jrtc27@jrtc27.com> writes:
> All I wanted was some simple extension string -> version number function
> as a standardised userspace interface... because at the end of the day
> people just want to know “can I use extension Y?”, possibly with a
> minimum version. But maybe there’s some hope that Linux libcs will
> translate such queries into poking at this hwprobe thing.
Using hwprobe to plumb such an interface for, say libcs, was what I was
envisioning.
> Though god knows what they’re going to do about vendor extensions,
> especially if those vendor extensions only get supported in vendor
> forks of the kernel (who’s allocating their encodings? Xvendorfoo
> exists to namespace them and give vendors control...).
"they're"? I'm sure your input on how to design such an interface would
be be much appreciated!
My view is that the "design upfront" strategy here hasn't really worked
out, so the hwprobe approach is to start small, and extend when there's
need. Hopefully, there will be fewer pains with this approach.
That's why I was very surprised to see this series, which introduces Yet
Another Interface.
Björn
next prev parent reply other threads:[~2023-05-02 5:50 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-24 19:49 Heiko Stuebner
2023-04-24 19:49 ` [PATCH 1/4] RISC-V: create ISA string separately - not as part of cpuinfo Heiko Stuebner
2023-04-24 23:06 ` kernel test robot
2023-04-25 8:45 ` kernel test robot
2023-04-26 9:26 ` Andrew Jones
2023-04-26 9:44 ` Andrew Jones
2023-05-01 14:52 ` Palmer Dabbelt
2023-04-24 19:49 ` [PATCH 2/4] RISC-V: don't parse dt isa string to get rv32/rv64 Heiko Stuebner
2023-04-26 9:37 ` Andrew Jones
2023-05-01 14:51 ` Palmer Dabbelt
2023-04-24 19:49 ` [PATCH 3/4] RISC-V: export the ISA string of the running machine in the aux vector Heiko Stuebner
2023-04-25 8:13 ` kernel test robot
2023-04-25 8:13 ` kernel test robot
2023-04-26 9:40 ` Andrew Jones
2023-04-24 19:49 ` [PATCH 4/4] RISC-V: add support for vendor-extensions via AT_BASE_PLATFORM and xthead Heiko Stuebner
2023-04-26 9:42 ` Andrew Jones
2023-04-26 12:29 ` Conor Dooley
2023-04-27 17:15 ` Heiko Stübner
2023-04-27 18:28 ` Conor Dooley
2023-04-28 7:53 ` Conor Dooley
2023-04-28 10:28 ` Andrew Jones
2023-04-28 14:25 ` Conor Dooley
2023-04-28 14:57 ` [PATCH 0/4] Expose the isa-string via the AT_BASE_PLATFORM aux vector Palmer Dabbelt
2023-04-28 18:48 ` Christoph Müllner
2023-04-28 18:59 ` Philipp Tomsich
2023-04-28 19:28 ` Palmer Dabbelt
2023-04-28 19:52 ` Palmer Dabbelt
2023-04-30 7:32 ` Shengyu Qu
2023-05-01 19:55 ` Björn Töpel
2023-05-01 20:08 ` Jessica Clarke
2023-05-02 5:48 ` Björn Töpel [this message]
2023-05-02 7:03 ` Philipp Tomsich
2023-05-02 7:58 ` Björn Töpel
2023-05-02 9:13 ` Philipp Tomsich
2023-05-02 10:09 ` Björn Töpel
2023-05-02 17:15 ` Palmer Dabbelt
2023-05-03 10:30 ` Heiko Stübner
2023-05-08 16:49 ` Evan Green
[not found] ` <CAAeLtUDgWwT0wxhFANagBX4ExA_HkyqM-ZdPn==+_atGV3vTww@mail.gmail.com>
2023-05-08 17:34 ` Philipp Tomsich
2023-05-08 17:38 ` Jessica Clarke
2023-05-09 17:23 ` Evan Green
2023-05-02 14:55 ` Palmer Dabbelt
[not found] <CABpcLcSTEegLcbWvs7NCvThvnpo8BQ1Gn9kRdEfe_ZobvYG1jg@mail.gmail.com>
2023-04-28 20:23 ` Palmer Dabbelt
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=878re77085.fsf@all.your.base.are.belong.to.us \
--to=bjorn@kernel.org \
--cc=arnd@arndb.de \
--cc=christoph.muellner@vrull.eu \
--cc=conor.dooley@microchip.com \
--cc=greentime.hu@sifive.com \
--cc=heiko.stuebner@vrull.eu \
--cc=heiko@sntech.de \
--cc=heinrich.schuchardt@canonical.com \
--cc=jrtc27@jrtc27.com \
--cc=kito.cheng@sifive.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=nick.knight@sifive.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=philipp.tomsich@vrull.eu \
--cc=richard.henderson@linaro.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®