Extend layer/driver JSON manifest to list library dependencies as a hint

[smcv]

What enhancement are you suggesting for the Vulkan Loader? Please describe in detail.

Some frameworks need to use Linux namespaces to run Vulkan programs in a container or sandbox:

• Chrome/Chromium sets up a sandbox environment for security, but needs to make graphics drivers available in that sandbox (I don't know whether it needs Vulkan specifically, but it will certainly want EGL, which has a similar structure)
• Steam's pressure-vessel framework sets up a container environment for library ABI management (to get a predictable version of application-level libraries like SDL and GTK), but, again, needs to make graphics drivers available in that container (in this case we certainly want both Vulkan and EGL)

It's not always straightforward to know what is considered to be part of the driver. When enumerating Vulkan drivers and layers, we know that we need the library_path. However, the library_path can have dependencies, either by ordinary dynamic linking (ELF DT_NEEDED on Linux, which we can discover programmatically by parsing ELF headers) or dynamically at runtime (dlopen() on Linux, which we cannot discover programmatically - currently the only way to know what is needed is to load the driver and let it run its arbitrary code).

For Mesa, it's enough to load the Vulkan driver via its library_path and then follow the DT_NEEDED tree; but the Nvidia proprietary driver uses dlopen() to load parts of itself, so following the DT_NEEDED tree is not necessarily sufficient. As a result, the Nvidia team have been in contact with Chrome and pressure-vessel developers about providing and parsing a manifest that would tell those tools what other libraries are needed.

It occurs to me that for Vulkan and other driver-loaders that mimic its structure (like GLVND EGL) we already have a perfectly good manifest that describes the driver, so it might make sense to put library information into the Vulkan driver's JSON manifest instead of inventing a separate file?

A straw-man example:

{
    "file_format_version" : "1.0.0",
    "ICD": {
        "library_path": "libGLX_nvidia.so.0",
        "api_version" : "1.3.242",
        "wants_libraries": [
            "libnvidia-cfg.so.1",
            "libnvidia-glcore.so.535.113.01",
            "..."
        ]
    }
}

The spec for wants_libraries could perhaps be something like this:

"wants_libraries"

An array of library names that the library_path might load, either via normal dependency loading such as Windows DLL dependencies or ELF DT_NEEDED, or via runtime dynamic loading such as Windows LoadLibrary or Linux dlopen. Sandboxing and container frameworks can use this as a hint to make those libraries available in the sandbox or container whenever this driver is in use. The syntax of each library name in the array is the same as library_path: a plain filename with no directory separators is to be looked up in the system's shared object search path, a relative path is relative to the JSON manifest, and an absolute path is loaded directly. Libraries in this array are not necessarily mandatory dependencies, so if not all of them can be found, loaders and container frameworks should attempt to proceed with the subset of libraries that can be found. This field is optional.

Is this specific to a single platform? I'm personally only interested in this for Linux, but it seems equally applicable to other Unix platforms like *BSD and Hurd, and it doesn't seem as though there's any reason this couldn't be generalized to macOS and Windows too.

Additional context

• https://groups.google.com/a/chromium.org/g/graphics-dev/c/nsq8J9vGmaQ
• https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/issues/123

cc @cubanismo - does this seem like a reasonable solution?