On Tue, 13 Jan 2026 16:01:51 -0800
Eric Biggers <[email protected]> wrote:
..
> A similar problem exists with the architecture-optimized CRC and crypto
> functions. Historically, these subsystems exported both generic and
> architecture-optimized functions.
>
> We've actually been moving away from that design to simplify things.
> For example, for CRC-32C there's now just the crc32c() function which
> delegates to the "best" CRC-32C implementation, with no direct access to
> the generic implementation of CRC-32C.
>
> crc_kunit then just tests and benchmarks crc32c(). To check how the
> performance of crc32c() changes when its implementation changes (whether
> the change is the addition of an arch-optimized implementation or a
> change in an existing arch-optimized implementation), the developer just
> needs to run crc_kunit with two kernels, before and after.
For the mul_div tests I arranged that the test code could #include the
source for the generic implementation so it could run that as well as
the version compiled into the main kernel.
This involved wrapping the function in:
#if !defined(function) || defined(test_function)
type function(args)
...
}
#if !defined(function)
EXPORT_SYMBOL(function)
#endif
#endif
So the test code can use:
#define function generic_function
#define test_function
#include "function.c"
to get a private copy of the generic code.
David
