On Thu, Jan 15, 2026 at 8:51 AM Feng Jiang <[email protected]> wrote: > On 2026/1/14 18:10, David Laight wrote: > > 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. > > Thank you for the suggestion! That technique is very clever and interesting— > I've definitely learned something new and will keep it in mind for the future. > > However, since lib/string.c is such a foundational and low-level library, I'm > hesitant to add macro wrappers or conditional blocks for KUnit. Given its > importance, I feel that increasing its complexity for side-by-side testing > isn't quite worth it. I'd prefer to keep the core code clean and follow Eric's > minimalist approach of benchmarking across different kernel configurations. > > I really appreciate the guidance! I second you, we currently may stick with what Eric proposed and consider other approaches in the future where appropriate. -- With Best Regards, Andy Shevchenko
