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

[Matt Turner]

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.

> 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.