On 2024-09-12 09:38, Daniel P. Berrangé wrote:
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.
The main difference is that FEX is faster for common workloads (say,
running games), and that it provides a way to transparently wrap
libraries (which is part of the reason why it's faster). We'll update
the Change to document this (and how it compares to other emulators like
box64), thanks for bringing it up.
== 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 ?
Yup, this was brought up on Discourse as well and is something we need
to test.
== 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 ?
This is an interesting idea. I suspect it might be out of scope for this
Change, but I'd be interested in exploring whether it could be viable. I
agree that if we can avoid hardcoding implementations that would be
nicer, but because different implementations make different tradeoffs
they might not be 100% interchangeable in practice.
Cheers
Davide
--
_______________________________________________
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
