Re: [PATCH 2/2] crypto/crc32[c]: register only "-lib" drivers

[David Sterba]

On Fri, Jun 13, 2025 at 11:37:53AM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@xxxxxxxxxx>
> 
> For the "crc32" and "crc32c" shash algorithms, instead of registering
> "*-generic" drivers as well as conditionally registering "*-$(ARCH)"
> drivers, instead just register "*-lib" drivers.  These just use the
> regular library functions crc32_le() and crc32c(), so they just do the
> right thing and are fully accelerated when supported by the CPU.
> 
> This eliminates the need for the CRC library to export crc32_le_base()
> and crc32c_base().  Separate patches make those static functions.
> 
> Since this patch removes the "crc32-generic" and "crc32c-generic" driver
> names which crypto/testmgr.c expects to exist, update crypto/testmgr.c
> accordingly.  This does mean that crypto/testmgr.c will no longer
> fuzz-test the "generic" implementation against the "arch" implementation
> for crc32 and crc32c, but this was redundant with crc_kunit anyway.
> 
> Besides the above, and btrfs_init_csum_hash() which the previous patch
> fixed, no code appears to have been relying on the "crc32-generic" or
> "crc32c-generic" driver names specifically.
> 
> btrfs does export the checksum driver name in
> /sys/fs/btrfs/$uuid/checksum.  This patch makes that file contain
> "crc32c-lib" instead of "crc32c-generic" or "crc32c-$(ARCH)".  This
> should be fine, since in practice the purpose of this file seems to have
> been just to allow users to manually check whether they needed to enable
> the optimized CRC32C code.  This was needed only because of the bug in
> old kernels where the optimized CRC32C code defaulted to off and even
> needed to be explicitly added to the ramdisk to be used.  Now that it
> just works in Linux 6.14 and later, there's no need for users to take
> any action and this file is basically obsolete.

Well, not the whole file, because it says which checksumming algo is
used for the filesystem, but the implementation part is.