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: > > On Thu, 29 May 2025 at 14:16, Eric Biggers <ebigg...@kernel.org> wrote: > > > > > > 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-ebigg...@kernel.org. 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
