On Sun, 19 Jan 2025 at 14:51, Eric Biggers <ebiggers@xxxxxxxxxx> wrote:
>
> - Reorganize the architecture-optimized CRC32 and CRC-T10DIF code to be
> directly accessible via the library API, instead of requiring the
> crypto API. This is much simpler and more efficient.
I'm not a fan of the crazy crypto interfaces for simple hashes that
only complicate and slow things down, so I'm all in favor of this and
have pulled it.
HOWEVER.
I'm also very much not a fan of asking users pointless questions.
What does this patch-set ask users idiotic questions like
CRC-T10DIF implementation
> 1. Architecture-optimized (CRC_T10DIF_IMPL_ARCH) (NEW)
2. Generic implementation (CRC_T10DIF_IMPL_GENERIC) (NEW)
and
CRC32 implementation
> 1. Arch-optimized, with fallback to slice-by-8
(CRC32_IMPL_ARCH_PLUS_SLICEBY8) (NEW)
2. Arch-optimized, with fallback to slice-by-1
(CRC32_IMPL_ARCH_PLUS_SLICEBY1) (NEW)
3. Slice by 8 bytes (CRC32_IMPL_SLICEBY8) (NEW)
4. Slice by 4 bytes (CRC32_IMPL_SLICEBY4) (NEW)
5. Slice by 1 byte (Sarwate's algorithm) (CRC32_IMPL_SLICEBY1) (NEW)
6. Classic Algorithm (one bit at a time) (CRC32_IMPL_BIT) (NEW)
because *nobody* wants to see that completely pointless noise.
Pick the best one. Don't ask the user to pick the best one.
If you have some really strong argument for why users need to be able
to override the sane choice, make the question it at *least* depend on
EXPERT.
And honestly, I don't see how there could possibly ever be any point.
If there is an arch-optimized version, just use it.
And if the "optimized" version is crap and worse than some generic
one, it just needs to be removed.
None of this "make the user make the choice because kernel developers
can't deal with the responsibility of just saying what is best".
Linus
