[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Z6w2HNjkFo4jvP3s@gondor.apana.org.au>
Date: Wed, 12 Feb 2025 13:48:12 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Eric Biggers <ebiggers@...nel.org>
Cc: kernel test robot <lkp@...el.com>, Danny Tsen <dtsen@...ux.ibm.com>,
oe-kbuild-all@...ts.linux.dev, linux-kernel@...r.kernel.org,
Ard Biesheuvel <ardb@...nel.org>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>
Subject: Re: [PATCH] crypto: lib/Kconfig - Fix lib built-in failure when arch
is modular
On Wed, Feb 12, 2025 at 05:44:28AM +0000, Eric Biggers wrote:
>
> The way that the arch options are selected is very much related to this issue,
> but even disregarding that the first paragraph of my response is a review
> comment directly on this patch about the naming it uses.
The CRC situation is not the same unfortunately. For better or
worse, the crypto API glue code is currently entangled with the
lib/crypto arch code. Meaning that a single Kconfig option ends
up selecting both.
So I don't see how the MAY_HAVE options can map onto the ones that
you've used for CRC.
Sure you can clean this up and perhaps make the lib/crypto arch
code always built-in. But that is not something I wish to spend
time on.
In any case, none of these new options are publicly exposed so
you can rename them down the line with very little effort.
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists