On Thu, Sep 12, 2024 at 04:50:39PM +0100, Aoife Moloney wrote: > == Owner == > * Name: [[User:dcavalca|Davide Cavalca]], [[User:ngompa|Neal Gompa]], > [[User:alyssa|Alyssa Rosenzweig]] > * Responsible Teams: [[SIGs/Asahi|Asahi SIG]], [[SIGs/KDE|KDE SIG]] > * Email: davide(at)cavalca.name, ngompa13(at)gmail.com, alyssa(at)rosenzweig.io > > > == Detailed Description == > When running Fedora Linux on an AArch64 host, one can normally only > run AArch64 binaries. This can be a problem if the user needs to run > preexisting software that was built for x86 or x86-64, which is still > the predominant architecture. If the software is opensource it can > sometimes be recompiled (or, even better, packaged in Fedora), but > this isn't always an option and could require significant work on the > user's part. For proprietary software, there is no viable option short > of persuading the author to release a native AArch64 build. > > FEX allows the user to sidestep this issue entirely by making it > possible to run x86 and x86-64 binares on AArch64 Linux hosts, as if > they were native. FEX achieves this via emulation, and it integrates > with the binfmts infrastructure to provide a seamless experience. To > ensure wide compatibility, FEX is also able to leverage a > distribution-shipped root filesystem tree (RootFS) to provide core > system libraries that the emulated binaries might need. This is describing what QEMU user emulators already provide for users, on any host arch. Perhaps acknowledge that QEMU user exists, and explain why users would prefer FEX vs QEMU, as I presume there are probably some noteworthy differences that matter. > == Benefit to Fedora == > Users will be able to run x86 and x86-64 binaries out of the box when > running Fedora Linux on their Aarch64 systems. This particularly > improves the usability of Fedora KDE for day-to-day usage on AArch64 > systems. Again, explain why this is better or different to what QEMU provides. NB, I've no objection to FEX being added, it is totally fine to have multiple impls of the same concept. Just want the feature page to give users some guidance on which direction to take when they have a choice of both. > == Upgrade/compatibility impact == > No expected upgrade or compatibility impact, this is a purely additive Change. Potential for interactions with QEMU's existing binfmt provision. Some packages pull in QEMU's emulators via deps, so if anything is pulling FEX in by default, then you could end up with both installed. systemd-binfmt.service man page says: "If multiple files specify the same option, the entry in the file with the lexicographically latest name will take precedence." QEMU adds /usr/lib/binfmt.d/qemu-XXXXX.conf files, so if FEX is adding /usr/lib/binfmt.d/fex-XXXX.conf files, QEMU would win if both were present, IIUC. This may or may not be the desirable outcome ? > == Dependencies == > This is pretty much self contained. Depending on the answer to the binfmt priority question, we might need co-ordinated changes with QEMU. For things which currently depend on QEMU, possibly we might want to generalize dependencies. Is a virtual "Provides: binfmt($target)" dep is appropriate, so things which need non-native binary support can avoid hardcoding a specific impl ? With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
