On Fri, May 30, 2025 at 12:18:58AM +0000, Eric Biggers wrote:

On Thu, May 29, 2025 at 04:54:34PM -0700, Linus Torvalds wrote:

quoted

On Thu, 29 May 2025 at 14:16, Eric Biggers [off-list ref] wrote:

quoted

So using crc32c() + ext4 + x86 as an example (but SHA-256 would be very
similar), the current behavior is that ext4.ko depends on the crc32c_arch()
symbol.

Yes, I think that's a good example.

I think it's an example of something that "works", but it certainly is
a bit hacky.

Wouldn't it be nicer if just plain "crc32c()" did the right thing,
instead of users having to do strange hacks just to get the optimized
version that they are looking for?

For crc32c() that's exactly how it works (since v6.14, when I implemented it).
The users call crc32c() which is an inline function, which then calls
crc32c_arch() or crc32c_base() depending on the kconfig.  So that's why I said
the symbol dependency is currently on crc32c_arch.  Sorry if I wasn't clear.
The SHA-256, ChaCha, and Poly1305 library code now has a similar design too.

If we merged the arch and generic modules together, then the symbol would become
crc32c.  But in either case crc32c() is the API that all the users call.

- Eric

I implemented my proposal, for lib/crc first, in
https://lore.kernel.org/lkml/20250601224441.778374-1-ebiggers@kernel.org (local).
I think it's strictly better than the status quo, and once applied to lib/crypto
it will solve some of the problems we've been having there too.  But let me know
if you still have misgivings.

- Eric