On 08/23/2016 02:45 PM, Emil Velikov wrote:
On 23 August 2016 at 19:05, Nicholas Miell <nmi...@gmail.com> wrote:
On 08/23/2016 02:07 AM, Emil Velikov wrote:

Skimmed through the discussion and I'm not sure the above will be enough.

Since the user is free to place json files in $HOME/.local ... this
implies that they may _not_ have access to /usr or /etc. Thus as they
install the file (to say $HOME/foo/lib) the Vulkan loader will not be
able to pick it up.


Why not?

Stick the 32-bit library in $HOME/foo/lib, the 64-bit library in
$HOME/foo/lib64, set library_path to "/home/emil/foo/$LIB/lib_mygpu.so" in
the $HOME/.local/share/vulkan/icd.d/mygpu.json file, and it should work,
right?

Few reasons:
 - If you use $LIB you also need to provide for all arches supported
by your setup. otherwise the loader will for missing files (small
nitpick but still).

The loader already handles this case.

 - conflict of who provides the json file - is it the x86-64 or i386
package, both, neither etc.

Both, assuming your package manager supports it (rpm) or stick it in an architecture-neutral package that the architecture-specific packages require (deb).

 - the vulkan loader is based on the presumption that can be multiple
drivers on the system. Each one clearly distinguished and described in
it's own json. Thus as ABI changes (gets updated) we must mandate that
distributions and users update both 64 and 32bit packages at the same
time. Otherwise there will be a miss-match between the described ABI
in json and the actual one of the binary/ies.

That's how distributions and package managers work already.

Json update:
 - the same file _cannot_ be provided by multiple packages


RPM certainly allows this, as long as the packages that provide the file
have the same name & version, different architectures, and the files are
byte-identical. Sticking $LIB in the path instead of "lib" or "lib64" makes
the files byte-identical.


Not everyone uses RPM, or even a package manager all together. In any
distro (mostly for source based ones) having one package overwrite
files of another package, is a serious no go. It may be allowed by
that's an exception of the general rule, requiring it's own list with
"ifs and buts".

Real world example: your distro ships the 64bit ICD, but not a 32bit
one. You build and install the latter yourself and as
  - you remove it (because of reasons) you end up breaking your 64bit setup
 -  or, you update the 64bit package and the contents of the json
change in a way that they don't reflect/describe your 32bit ICD.

That isn't a real world example, or at the very least its an example of a bad distribution that you shouldn't use combined with user error.


So all in all, without separate json files each describing a separate
ICD, things are extremely easy to break.

-Emil


_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to