public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
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]
-=-=-=-=-=-=-=-=-=-=-=-



             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