From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) by sourceware.org (Postfix) with ESMTP id 8FA363858D28; Mon, 17 Jul 2023 17:59:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8FA363858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org References: <20230717144859.2299315-1-adhemerval.zanella@linaro.org> <87sf9mbmyz.fsf@gentoo.org> <877cqybg1v.fsf@gentoo.org> <4a78fa61-366b-2acd-18c3-e11f44cc9ade@linaro.org> User-agent: mu4e 1.10.4; emacs 29.0.92 From: Sam James To: Adhemerval Zanella Netto Cc: Sam James , Siddhesh Poyarekar , libc-alpha@sourceware.org Subject: Re: [PATCH] sparc: Remove optimize md5, sha256, and sha512 Date: Mon, 17 Jul 2023 18:58:56 +0100 In-reply-to: <4a78fa61-366b-2acd-18c3-e11f44cc9ade@linaro.org> Message-ID: <87zg3ua06s.fsf@gentoo.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,KAM_NUMSUBJECT,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Adhemerval Zanella Netto writes: > On 17/07/23 14:31, Sam James wrote: >>=20 >> Adhemerval Zanella Netto writes: >>=20 >>> On 17/07/23 12:01, Sam James wrote: >>>> >>>> Adhemerval Zanella via Libc-alpha 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 reaso= n. >>> Maybe we can make crypt return ENOSYS as default, but even though I thi= nk >>> if libcrypt is still enabled we will need to keep old code as compat >>> layer.=20 >>> >>=20 >> 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. > >>=20 >> 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! --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZLWBi18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZC7pgD9GGL9V8xRbbKfeSjNpkkQwZxxP6CTEMLXS6Wm sQG77jEA/17Vx1JBhUNAB39FGQcLcHi0fbDI++wkgEoMtTpTQHoM =V776 -----END PGP SIGNATURE----- --=-=-=--