F42 Change Proposal: Integrate FEX in Fedora Linux (Self-Contained)

Project Discussion Change Proposals
,
21

Distros make default software choices all the time, it’s part of what being a distro is. Box64 isn’t left out since it’s packaged in Fedora (and I don’t think anyone ever proposed not doing so).

The first game I tried with box64 - which is a game in fact demoed on the box64 website - fails to launch on Fedora since it wants an x86_64 copy of libstdc++.so.6. I know you ship a bunch of those as binary blobs upstream, but that solution won’t work for Fedora policies, which is why they aren’t part of the package (built with -DNO_LIB_INSTALL). So perhaps someone should step up to figure out how to package non-thunked x86_64 libs in the Fedora package in a clean, maintainable way, using the Fedora builds of those libs just like we do for the FEX RootFS. That would make box64 a more usable option out of the box.

In any case, as you know, all this work is a volunteer effort. On the Asahi side we focused on FEX since 32-bit support is essentially mandatory for many applications that end-users want to run. box64 might be catching up to that now with box32, but it’s not ready yet, while FEX works today. I know the box64 solution has different trade-offs and works better for some use cases, but at the end of the day neither solution is perfect, and for better or worse distros are going to have to choose one to fully integrate first.

that box64 package is severly out of date. More than 1.5 year old.

The version currently packaged in all supported Fedora versions is box64 0.2.8, which was released in May this year.

Also also, box64 is compatible with 16k pagesize, and can run many games and program out-of-the box on 16k pagesize.

box64 uses hacks to support the 16K page size, which by their nature, can never achieve full compatibility (e.g. Wine does not work, as you know). Absent some significant breakthrough, a 4K VM or similar solution will be necessary for full compatibility on systems running with 16K pages, and at that point both box64 and FEX are on equal footing. While I do encourage people to use box64 where it works, I don’t think shipping it as the default x86 emulation solution without a VM on 16K systems like Fedora Asahi Remix is something I’d ever consider on my end, because it quite simply isn’t and will never be a solution with full compatibility, by its nature.

More constructively, I think it would be nice to have some kind of binfmt dispatch layer in the future, so both box64 (with or without a VM on 16K systems) and FEX can be used depending on what the user is trying to run exactly, with the best option chosen on an app/game-by-game basis. We’ve discussed this before but so far it’s been just an idea. If box64 learns how to use the libs in the FEX RootFS we are already integrating, that would give us a best-of-both-worlds solution and it would be a good reason to ship both options by default.

(Disclaimer: I don’t speak for Fedora, just for the Asahi Linux project, but as we’ve been the ones pushing for this Change and the FEX integration, I hope this helps clarify why we made that choice.)

2 Likes
22

Thanks for the detailled answer.

Yes, the binary libs, there is some work to make it independant. A next step to the -DNO_LIB_INSTALL switch. But again, using fedora own libstdlibc++.so.6 is completly doable and box64 is smart enough to find it.
Box32 is very much a work in progress, but already showing some result.
May this year, is still very old. This looks like an abandoned packaged to me, it’s not even updated to latest stable v0.3.0
Yes, the 16k pagesize “hacks” are not there to make 100% of the stuffs to work. That’s for sure. But yet, there are many things that does work fine. And you can use numerous GoG Linux games out-of-the box (provide you get stdc++ libs and x86_64 bash somewhere, but that is clearly solvable, and is certainly way easier to do than to use a full rootfs system).

(also, using the libs from fex rootfs is really simple, just tell me where the libs are and I add the folder in box64 search list. it’s just that I don’t see why I should download 1GB of stuff when 20M is enough)

But I’m not here to argument which emulation solution is the best.

The only thing I ask is that the binfmt shim to give a choice to the use to install the x86_64 emulation he wants and not force everyone to use 1 solution.

23

Note that the FEX rootfs isn’t “a whole distro”, it’s largely the libraries (and binaries most of which probably aren’t needed and probably will be removed).

it’s just that I don’t see why I should download 1GB of stuff when 20M is enough

I doubt that 20MB of libraries + box64 has the compatibility of FEX + the rootfs. By quick count, box64 wraps 241 libraries for 64-bit (and seemingly only 7 for box32? Not sure if this is correct, that’s very barebones if it is), while we ship 469 or so in the FEX rootfs (for both 32-bit and 64-bit). It’s impressive that box64 can thunk so many libraries, and thunking has performance advantages, but anything that isn’t thunked you still need to provide as an external library and then you’re back to the rootfs approach. FEX has some thunks too, and over time I suspect the rootfs will be slimmed down (e.g. right now it has 4 versions of LLVM or something silly like that, pretty sure that is not necessary).

1 Like
24

Again, I’m sure there are use case where the fex rootfs makes more sence, or other usecase where you would prefet a qemu approach, and some other where box64 approach is enough.

There are many use case, that why the binfmt shim should left the end-user choose which one, between FEX, qemu and box64 is the more appropriate instead of forcing FEX.

25

This doesn’t really exist yet. I expect we’ll definitely have a config file of sorts to pick which implementation to use, but I don’t think we’ll implement a “choose-your-browser”-style UI (or possibly any UI at all). As marcan said, it’s pretty normal for distributions to pick defaults, but that doesn’t mean the user is forced to use the preselected option.

We’re all volunteers here. I’ll try and get this updated, there already a PR up so assuming the CI passes it shouldn’t be too much trouble. In the future, if you see this (or any other) package lagging, feel free to ping the corresponding bug.

The package is fex-emu-rootfs-fedora, and it installs the rootfs in /usr/share/fex-emu/RootFS/default.erofs. The contents of the rootfs itself are defined in Kiwi.

1 Like