Re: [PATCH v2 00/17] SHA-512 library functions

[Eric Biggers <ebiggers@kernel.org>]

On Tue, Jun 17, 2025 at 11:29:15AM -0700, Linus Torvalds wrote:
> On Mon, 16 Jun 2025 at 23:05, Eric Biggers <ebiggers@kernel.org> wrote:
> >
> > An additional note on testing: [..]
> 
> Talking about testing - when adding test scripts, can you do it as a
> separate thing entirely - either before or after?
> 
> As it is, this code movement is hard to judge just because the stats
> are all messed up with new tests:
> 
>  77 files changed, 4012 insertions(+), 1756 deletions(-)
> 
> that's 2k+ new lines of code that pretty much entirely hides the
> question of "did this code movement result in a simpler / same / more
> complex end result".
> 
> So in general, I'd really prefer big re-organizations to be *separate*
> from new code changes.
> 
> It's just a pain to review renaming when it's mixed up with other
> changes - whether renaming variables or whole files.
> 
> And that's as true on an individual commit level (we try to avoid
> renaming things *and* making other changes in one go) as it is on a
> pull request level.
> 
> If I see a pull request that only adds new tests, it's a no-brainer.
> 
> If I see a pull request that only re-organizes the code and the
> diffstat just just renames with some small updates for new locations,
> it's a no-brainer.
> 
> If I see a pull request that does both, it's a pain in the arse,
> because then I need to start to look into individual commits and go
> "which does what".

The tests are already in their own patches: patches 4 and 5.  Yes, this patchset
has a negative diffstat once you subtract them.

(And most of the positive diffstat in the tests is generated test vectors.  The
rest is mostly code that I'll reuse later in tests for other hash functions; it
just gets blamed to this one because it's the first one.)

I'd really prefer to keep testing as a first-class citizen.  Tests should be
contributed along with the code itself.

And the point of this patchset is not just "code movement", but rather adding a
library API, including documentation *and tests*.

Later, I'll be converting various in-kernel users to use that API, just as I've
been doing for crc32 and sha256.  It's already been shown that the
"librarification" works well and is much simpler than the old-school Crypto API.

If you really want patches 4-5 in a separate patchset that's based on this one,
I can do that.  Ultimately, the result would be the same.

I think your request for there to be a separate "tests" pull request is a
non-starter, though.  That would imply separate git trees, and we then wouldn't
be able to land tests at the same time as the code itself.

- Eric