[Mesa-dev] [PATCH] anv: Give the installed intel_icd.json file an absolute path

Nicholas Miell nmiell at gmail.com
Tue Aug 23 21:56:08 UTC 2016


On 08/23/2016 02:45 PM, Emil Velikov wrote:
> On 23 August 2016 at 19:05, Nicholas Miell <nmiell at 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
>



More information about the mesa-dev mailing list