[Mesa-dev] [PATCH] mesa: Add mesa SHA-1 functions

[Emil Velikov]

On 15/12/14 17:19, Matt Turner wrote:
> On Mon, Dec 15, 2014 at 3:15 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 14/12/14 17:19, Matt Turner wrote:
>>> On Sun, Dec 14, 2014 at 7:06 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>>> On 11/12/14 21:51, Carl Worth wrote:
>>>>> From: Kristian Høgsberg <krh at bitplanet.net>
>>>>>
>>>>> The upcoming shader cache uses the SHA-1 algorithm for cryptographic
>>>>> naming. These new mesa_sha1 functions are implemented with the nettle
>>>>> library.
>>>>> ---
>>>>>
>>>>> This patch is another in support of my upcoming shader-cache work. Thanks to
>>>>> Kritian for coding this piece.
>>>>>
>>>>> As currently written, this patch introduces a new dependency of Mesa on the
>>>>> Nettle library to implement SHA-1. I'm open to recommendations if people would prefer some other option.
>>>>>
>>>>> For example, the xserver can be configured to get a SHA-1 implementation from
>>>>> libmd, libc, CommonCrypto, CryptoAPI, libnettle, libgcrypt, libsha1, or
>>>>> openssl.
>>>>>
>>>>> I don't know if it's important to offer as many options as that, which is why
>>>>> I'm asking for opinions here.
>>>>>
>>>> Hi Carl,
>>>>
>>>> Can we try to avoid adding new dependencies to mesa unless absolutely
>>>> needed. Neither of the proprietary drivers does so presently, so it will
>>>> be nice to keep the trend.
>>>>
>>>> While currently the steam runtime does not include libnettle I can
>>>> envision one day that they will/might. Even with steam aside I think
>>>> that this might cause issues with gnome & others' sandboxing.
>>>>
>>>> Long story short - can we import a sha1 implementation from another
>>>> project ? It will save us the "libstdc++ style steam runtime" issues,
>>>> plus it will ease the question of what to do under Windows :)
>>>
>>> It's working okay for the xserver, isn't it?
>>>
>> The xserver is linking against libudev and we all know how nicely that
>> one went.
> 
> Sorry, I don't actually.
> 
Check out commit 4556c734700(loader: Use dlsym to get our udev symbols
instead of explicit linking.) or 63546b8e3d2(dri: Also support the
loader with libudev.so.0.) and their relevant bug reports.

Hope that you're aware about the libgcc_s/libstdc++ issue. If not check
out [1] or just google "steam+linux+libstdc++". You'll find dozens of
reports.

>> Here are the libs that we're missing wrt xserver:
>>   NEEDED               libdbus-1.so.3
>>   NEEDED               libudev.so.1
>>   NEEDED               libgcrypt.so.20
>>   NEEDED               libpciaccess.so.0
>>   NEEDED               libpixman-1.so.0
>>   NEEDED               libXfont.so.1
>>   NEEDED               libXau.so.6
>>   NEEDED               libsystemd.so.0
>>   NEEDED               libxshmfence.so.1
>>   NEEDED               libXdmcp.so.6
>>
>>
>> Imho going for a "having as little external dependencies as possible"
>> sounds better than "how many can we stuff in and get away with".
>> Admittedly those are extraditions yet they nicely indicate the opposing
>> directions.
> 
> This sounds like a false dilemma.
> 
> Let's try doing what the xserver does as a first approximation and if
> we discover problems we can revisit.
> 
Going with that assumption is known to not be the best of ideas. Why do
you insist on repeating it, is what worries me.


Cheers,
Emil

[1] https://wiki.archlinux.org/index.php/Steam#Steam_runtime_issues