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

[Emil Velikov]

On 23 August 2016 at 22:56, Nicholas Miell <nmiell at gmail.com> wrote:
> 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.
>
Even so, lying/misleading to the loader isn't the nicest thing to do.

>>  - 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).
>
As previously below you _cannot_ assume that a package manager (if
any) can handle with this.

>>  - 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.
>
Almost, but not quite:
 - Many distros give the user and option to select which package to
update. Thus the user can shoot themselves in the foot because they're
not familiar with this unique Vulkan specifics.
 - At least two distros have ~24h or more period between 64bit and the
multilib package are rolled out.

>>>> 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.
>
Again, almost.
Archlinux does not (last checked a few minutes ago) does not ship
multilib vulkan. While it has a fair few drawbacks it is in no means
bad one imho. If I am to build and install a multilib one - be that a
proper package or not, I will exhibit the issues described above.

And yes I wish things were as simple as using $LIB. Yet, realistically
one cannot expect that every distribution (let's ignore the LFS alike
ones for the time being) follows the approaches used by the distro you
have in mind.

Regards,
Emil