On 1/22/24 20:04, Rebecca Cran wrote: > 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.
This list seems too restrictive. As long as IHVs are not interested in their cards booting on non-x86 boards, nothing sustainable can be done. Assuming IHVs are *slightly* interested (which does not mean "full support" at all), things can be done. Among those things, binary-based approaches are all futile, IMO, because they do not allow for debugging and improvements by the *board* vendor. EBC, WASM, eBFP, constrained X64 are all the same in this regard. If the original driver doesn't perform proper mapping for DMA for example, that issue can only be identified and fixed by *source-level* work. IMO the only sustainable approach is if an IHV licenses the source code of their driver (containing X64 shortcuts) to the vendor of the (non-x86) board, preferably including documentation. Then the board vendor can identify issues, and propose source-level fixes. That's less burden on the IHV (mostly just regression testing on x86) than taking on full support themselves. Regarding distribution, the non-x86 binaries could be distributed on USB sticks (and loaded via Driver####), possibly even by the board vendor. Not super comfortable for the end-user, but it would not intrude on the card flash (so the IHV wouldn't have to account for it). Of course this requires the IHV to be willing to show their source code to the board vendor (possibly under NDA). Until that happens, this mess will persist. In my opinion. Either way, I believe that this option is not represented in the survey. Laszlo > > 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 (#114203): https://edk2.groups.io/g/devel/message/114203 Mute This Topic: https://groups.io/mt/103910445/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
