Skip to content

Distinguish between direct I/O and sysroots

Simon McVittie requested to merge wip/smcv/sysroot-object into main

/cc @denittis


  • !611 (merged)

  • sysroot: Introduce a small object to represent a sysroot

    This keeps track of whether the sysroot is "direct", meaning that we can use a more naive approach to I/O while acting on the real system root. This allows frameworks like FEX-Emu to adjust filesystem resolution via its pseudo-overlay "rootfs".

  • system-info: Have a SrtSysroot object

    This currently assumes that sysroot = / is synonymous with using direct I/O for access to the sysroot. There is no difference yet, but there will be in a future commit.

    This also forces us to be more careful about tracking whether the sysroot was opened successfully: if it wasn't, self->sysroot will now be null, and we have to cope with that.

    A small functional change in this commit is that the given sysroot was previously opened with O_NOFOLLOW, so the last path component was required to be a non-symlink. Now it follows symlinks, including "magic symlinks" like /proc/self/root.

  • sysroot: Add _srt_sysroot_open

    Unlike _srt_resolve_in_sysroot, this has a direct code path, which opens files in a more naive way while acting on the real system root. This allows frameworks like FEX-Emu to adjust filesystem resolution via its pseudo-overlay "rootfs".

    When working with a non-trivial sysroot, we continue to use _srt_resolve_in_sysroot() as before.

  • tests: Add test coverage for sysroot-relative file I/O

  • graphics: Propagate the SrtSysroot object while finding DRI-like modules

    No functional change intended, this is just passing around the (path, sysroot) pair as a single object.

  • graphics: Use direct I/O to find DRI-like modules if appropriate

    This means we will find the same DRI, VA-API and VDPAU modules that the actual loader libraries would find, taking into account FEX-Emu's pseudo-overlayfs.

    steamrt/tasks#347

  • sysroot: Add a sysroot-aware version of g_file_get_contents()

    This is similar to (and should eventually replace) _srt_file_get_contents_in_sysroot(), but will use direct I/O if appropriate, for better FEX-Emu compatibility.

  • os: Take a SrtSysroot object

    No functional change intended, this is just bundling the (path, fd) pair into an object.

  • os: Use direct I/O to open /etc/os-release if appropriate

    When running under FEX-Emu this means we will find the same /etc/os-release that a naive x86 process would, taking into account FEX-Emu's pseudo-overlayfs.

    steamrt/tasks#342

  • system-info: Resolve ld.so with direct I/O if appropriate

    When running under FEX-Emu this means we will find the same version of ld.so that a naive x86 process would, taking into account FEX-Emu's pseudo-overlayfs. The output path even includes the FEX rootfs prefix, which is a nice bonus when using this as a diagnostic tool.

    steamrt/tasks#348

  • _srt_recursive_list_content: Take the top fd as an optional parameter

    This is intentionally not using a SrtSysroot, because for some callers we are listing contents relative to a path that is not, technically, a sysroot.

  • system-info: Use direct I/O to list /overrides if appropriate

    As with previous commits, this means we get the right answer when running under FEX-Emu.

  • sysroot: Add a simplified interface

    We can use this as a replacement for most uses of _srt_file_test_in_sysroot().

  • container: Use SrtSysroot to access paths in sysroot

    This prevents symlinks from inadvertently "escaping" from the sysroot, while also doing the right thing to take into account FEX-Emu's pseudo-overlayfs.

  • virtualization: Use a SrtSysroot for fd-relative I/O if appropriate

  • utils: Remove _srt_file_get_contents_in_sysroot()

    Superseded by _srt_sysroot_load().

Edited by Simon McVittie

Merge request reports