Re: [PATCH] sparc: Remove optimize md5, sha256, and sha512

[Sam James <sam@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2101 bytes --]


Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> writes:

> On 17/07/23 14:31, Sam James wrote:
>> 
>> Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> writes:
>> 
>>> On 17/07/23 12:01, Sam James wrote:
>>>>
>>>> Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org> writes:
>>>>
>>>>> The libcrypt was maked to phase out on 2.28, and better projects
>>>>> already exist that provide both compatibility and better API
>>>>> (libxcrypt).  The sparc optimizations add the burden to extra
>>>>> build-many-glibcs.py configurations.
>>>>>
>>>>
>>>> I guess. I'd personally prefer just removing it all when libcrypt
>>>> is removed, not hacking away at it beforehand.
>>>
>>> I don't think we will ever be able to remove libgcrypt due compat reason.
>>> Maybe we can make crypt return ENOSYS as default, but even though I think
>>> if libcrypt is still enabled we will need to keep old code as compat
>>> layer. 
>>>
>> 
>> In the other thread, we're talking about when it's time to kill it
>> entirely (I suppose just the option to build, not the real
>> implementation).
>
> I am not sure what kind of compatibility we will need to preserve for
> libcrypto.  For sunrpc 5500cdba401), we have removed most of the symbols
> but still kept some old ones for compatibility even though the
> libtirpc does implement such symbols (like key_setsecret for instance).
>
> It seems that libcrypto is way simpler, and libxcrypt does implement
> all require symbol version which the expected. So it should be doable.
>
>> 
>> My assumption was we'd remove optimisations like this at that point.
>
> The idea of the patch is to streamline the required build coverage to
> avoid having a --enable-crypt just for sparc.  Sure we can pack if/when
> we remove libcrypto, but I think this is orthogonal.

You feel strongly so it's fine with me to yank it then, I just felt it
was cleaner to not "soft-kill" it before it was removed, but you're right
that it's unclear how we're even going to remove it and how far.

Objection withdrawn - thanks!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]