IRC channel logs

<Qaridarium>Subject: Proposal for an ELF-SXS/SHIM System for Linux Binary Compatibility

<Qaridarium>Here is an explanation of the historical Solaris compatibility model and a proposal for a modern Linux equivalent: the ELF-SXS/SHIM System. This system combines Nix-style storage, kernel namespacing, and JIT binary patching to solve complex compatibility issues.

<Qaridarium>1. The Inspiration: Solaris 1998 SXS and SHIMs

<Qaridarium>In Solaris 7, the OS solved legacy compatibility using two key mechanisms:

<Qaridarium>SXS (Side-by-Side): Utilizing the ORIGIN token to allow binaries to load dependencies relative to themselves. This enabled multiple library versions to exist side-by-side without polluting the global namespace.

<Qaridarium>SHIMs: Using the Binary Compatibility Package to trap and translate old system calls on-the-fly, allowing unmodified legacy executables to run on a newer kernel.

<Qaridarium>2. The Solution: The ELF-SXS/SHIM Linux System

<Qaridarium>To solve the "binary compatibility problem" on Linux—especially when modern drivers cannot share an address space with legacy applications—we propose a system composed of three layers.

<Qaridarium>A. Storage: Nix-Style SXS Directory Format Instead of a traditional file system hierarchy (FHS), this system uses a storage format inspired by Nix.

<Qaridarium>Hashed Directories: Libraries and dependencies are stored in unique, immutable directories derived from a cryptographic hash of their build configuration (e.g., /store/unique-hash-glibc-2.25).

<Qaridarium>True Side-by-Side: This allows infinite versions of the same library (SXS) to exist globally on the host without conflict. The legacy application simply binds to the specific hashed path it requires, ignoring the host's standard libraries.

<Qaridarium>B. Isolation: Cgroups and Namespaces We emulate the "Solaris Zones" functionality using standard Linux kernel features:

<Qaridarium>Namespaces: We use Mount and PID namespaces to construct a virtual view for the application. The specific "Nix-style" library paths are bind-mounted into standard locations (like /lib) inside the namespace. The app sees a standard environment, but it is physically backed by the immutable SXS store.

<Qaridarium>Cgroups: We apply Control Groups to limit resource usage (CPU/Memory), ensuring the legacy container cannot exhaust host resources.

<Qaridarium>C. The Runtime Shim: Shiva and Unix Sockets For cases where new code (like a modern Wayland driver) absolutely cannot be loaded into the legacy address space due to symbol conflicts (e.g., Glibc version mismatches), we use a shim architecture:

<Qaridarium>Shiva JIT Patching: We use the Shiva system to load the legacy binary. Instead of modifying the file on disk, Shiva patches the binary in memory at runtime.

<Qaridarium>Socket Separation: Shiva rewrites specific function calls to redirect them over a Unix Domain Socket.

<Qaridarium>The Helper: A separate process running in the modern host environment listens on this socket, executes the driver logic, and returns the result. This ensures the legacy app and the modern driver never touch the same memory space.

<Qaridarium>can anyone tell me if this is a good idea ?

<Qaridarium> https://www.phoronix.com/forums/forum/software/general-linux-open-source/1604257-flatpak-exploring-gpu-virtualization-to-ease-driver-challenges/page11#post1605531

<Qaridarium>slalomsk8er : How about chatting with the Guix folks on IRC? They seam to be very academically minded - at least the HPC bunch.

IRC channel logs

2026-01-31.log