From: "Rebecca Cran" <rebecca@bsdio.com>
To: "devel@edk2.groups.io" <devel@edk2.groups.io>
Cc: discuss@edk2.groups.io, "rfc@edk2.groups.io" <rfc@edk2.groups.io>
Subject: [edk2-devel] Multi-ISA Driver Compatibility Survey
Date: Mon, 22 Jan 2024 12:04:45 -0700 [thread overview]
Message-ID: <53d076f2-50a5-47d1-8df7-c0e3dace99ee@bsdio.com> (raw)
Originally posted at
https://twitter.com/UEFIForum/status/1745518769232077208
The Multi-ISA Driver Compatibility Survey is at
https://docs.google.com/forms/d/e/1FAIpQLScXjwaSBgLeqB1coEDxCPxho5JWF3AMqshOTJ2wd6Tf0He4LA/viewform
From that page:
Did you know Tiano today supports four 64-bit architectures, yet plug-in
device OpRoms are still mostly limited to x64 and CSM? While
binary-translation approaches are a useful stop-gap solution for both
AArch64 and RV64 ecosystems, we need a common approach that is not a
technical debt nightmare and that will be adopted by IHVs and endorsed
by OSVs.
The Multi-ISA Driver Compatibility talk went over some of the possible
approaches, as a lead-in for an open discussion, and raised the
long-term importance of solving cross-architecture compatibility issues
for OpRom drivers.
This survey is an opportunity provide feedback to guide further
exploration in this space.
The discussed options were:
- Do nothing. This is an IHV problem. IHV should continue shipping
support for whatever architectures they deem necessary.
- Resurrect EFI Byte Code. Invest in compilers and tooling (e.g.
addr2line, JIT, etc) to get parity with existing native drivers.
- Look at WASM, and solve tooling constraints (around sandboxing) that
prevent adoption.
- eBPF, and solve tooling constraints (around sandboxing) that prevent
adoption.
- Constrained, well-defined subset of x64. This meets IHVs half-way by
avoiding significant perturbations to existing driver development and
release processes, and achieves compatibility with existing x64 systems
in the market "for free", while addressing most of the concerns around
binary translation of x64 code.
Note: the last three options (WASM, eBPF and constrained x64) are not
neutral with respect to host natural register width, which will mean a
break in compatibility with future TBD 128-bit environments, unless a
TBD OpRom sandboxing technology is invented.
Note 2: emails and names/sign-ins are not collected, this is an
anonymous response.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114144): https://edk2.groups.io/g/devel/message/114144
Mute This Topic: https://groups.io/mt/103893425/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
next reply other threads:[~2024-01-22 19:04 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-22 19:04 Rebecca Cran [this message]
2024-01-23 14:44 ` [edk2-devel] [edk2-discuss] Multi-ISA Driver Compatibility Survey Laszlo Ersek
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-list 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=53d076f2-50a5-47d1-8df7-c0e3dace99ee@bsdio.com \
--to=devel@edk2.groups.io \
/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