Path resolution fixes
- FEXLoader: Strip rootfs path from CONFIG_APP_FILENAME
- FileManagement: Trace symlink paths across rootfs
:+1: I'll take a peek today and if needed over the next couple days to see what we can do to resolve these issues. Going to need a bunch of testing due to how likely this is to affect things like Proton and pressure-vessel.
@Sonicadvance1 Note that d9a8309 is not enough to fix wine, you still need b483c800 here since it's needed to make the /etc/alternatives stuff work with wine's path resolution.
@Sonicadvance1 Note that d9a8309 is not enough to fix wine, you still need b483c80 here since it's needed to make the /etc/alternatives stuff work with wine's path resolution.
Indeed, my PR is only a partial fix. I still need to work through the rest of the problems with rootfs symlink problem.
Rebased this on top of your change and fixed a bug that broke Steam
Added another patch to refuse to close the RootFS FD. This was already a hidden potential problem, but more specifically regresses Proton with the change to GetEmulatedPath to call GetEmulatedFDPath, since that uses the fd where it wasn't previously used.
Fixed the formatting (I think)
Fixed the formatting (I think)
fyi, this command can reformat the project for you sh -c "CLANG_FORMAT=clang-format-16 ./Scripts/reformat.sh . > /dev/null 2>&1"
This seems plausible to me but @Sonicadvance1 should probably review
What's the path (heh) forward for this? Does a proper fix need more looking into or are we considering integrating this PR as-is? I have reservations against the latter, but not sure they need to be elaborated.
My main worry about this is the performance implications of doing a lot more syscalls for some things, but I don't know that that is solvable without a major overhaul introducing caching or something like that...
What I was going to explore next is actually completely bypassing this whole mess and introducing an alternate mode where FEX only does RootFS lookups, using a kernel-side overlayfs and overlaid mounts to create the complete x86 view of the filesystem. I suspect that'll work better for our (muvm) use case and solve a large number of path resolution/rootfs related issues in FEX all at once (there are just about enough tricks with path resolution and POSIX/Linux syscalls available to make path resolution correctly implementable in this scenario, without any userspace path resolution at the component level).
But that only works for that setup. Assuming there isn't interest in moving to that solution fully as a baseline, I imagine we still want to improve the internal overlay logic as in this PR. And I think for that I need some FEX folks to weigh in, since I don't really know where to go from here.
On October 23, 2024 8:17:21 PM GMT+02:00, Tony Wasserka @.***> wrote:
What's the path (heh) forward for this? Does a proper fix need more looking into or are we considering integrating this PR as-is? I have reservations against the latter, but not sure they need to be elaborated.
-- Reply to this email directly or view it on GitHub: https://github.com/FEX-Emu/FEX/pull/3831#issuecomment-2433059848 You are receiving this because you authored the thread.
Message ID: @.***>