Re: [PATCH v2 01/14] lib/string: extract generic strlen() into __generic_strlen()

From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Feng Jiang <jiangfeng@kylinos.cn>,
	pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu,
	alex@ghiti.fr, kees@kernel.org, andy@kernel.org,
	akpm@linux-foundation.org, martin.petersen@oracle.com,
	ardb@kernel.org, ajones@ventanamicro.com,
	conor.dooley@microchip.com, samuel.holland@sifive.com,
	linus.walleij@linaro.org, nathan@kernel.org,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-hardening@vger.kernel.org
Subject: Re: [PATCH v2 01/14] lib/string: extract generic strlen() into __generic_strlen()
Date: Wed, 14 Jan 2026 09:07:44 +0200	[thread overview]
Message-ID: <aWdAwHy77V8EiDeX@smile.fi.intel.com> (raw)
In-Reply-To: <20260114000151.GB2178@quark>

On Tue, Jan 13, 2026 at 04:01:51PM -0800, Eric Biggers wrote:
> On Tue, Jan 13, 2026 at 04:27:35PM +0800, Feng Jiang wrote:
> > To support performance benchmarking in KUnit tests, extract the
> > generic C implementation of strlen() into a standalone function
> > __generic_strlen(). This allows tests to compare architecture-optimized
> > versions against the generic baseline without duplicating code.

...

> 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.
> 
> I suggest just doing that.  In that case there would be no need to
> export the generic implementations of these functions.

This also would work for me! Whatever, folks, you find the best from the
readability and maintenance point of view.

> (Also note that *if* the generic functions are exported, they probably
> should be exported only when the KUnit test is enabled.  There's no need
> to include them in the kernel image when the test isn't enabled.)

True.

-- 
With Best Regards,
Andy Shevchenko