From: Eric Biggers <ebiggers@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Alex Williamson <alex.williamson@redhat.com>,
linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-riscv@lists.infradead.org, sparclinux@vger.kernel.org,
linux-s390@vger.kernel.org, x86@kernel.org,
Ard Biesheuvel <ardb@kernel.org>,
"Jason A . Donenfeld" <Jason@zx2c4.com>
Subject: Re: [PATCH v4 08/13] crypto: s390/sha256 - implement library instead of shash
Date: Fri, 30 May 2025 00:18:58 +0000 [thread overview]
Message-ID: <20250530001858.GD3840196@google.com> (raw)
In-Reply-To: <CAHk-=wh+H-9649NHK5cayNKn0pmReH41rvG6hWee+oposb3EUg@mail.gmail.com>
On Thu, May 29, 2025 at 04:54:34PM -0700, Linus Torvalds wrote:
> On Thu, 29 May 2025 at 14:16, Eric Biggers <ebiggers@kernel.org> wrote:
> >
> > So using crc32c() + ext4 + x86 as an example (but SHA-256 would be very
> > similar), the current behavior is that ext4.ko depends on the crc32c_arch()
> > symbol.
>
> Yes, I think that's a good example.
>
> I think it's an example of something that "works", but it certainly is
> a bit hacky.
>
> Wouldn't it be nicer if just plain "crc32c()" did the right thing,
> instead of users having to do strange hacks just to get the optimized
> version that they are looking for?
For crc32c() that's exactly how it works (since v6.14, when I implemented it).
The users call crc32c() which is an inline function, which then calls
crc32c_arch() or crc32c_base() depending on the kconfig. So that's why I said
the symbol dependency is currently on crc32c_arch. Sorry if I wasn't clear.
The SHA-256, ChaCha, and Poly1305 library code now has a similar design too.
If we merged the arch and generic modules together, then the symbol would become
crc32c. But in either case crc32c() is the API that all the users call.
- Eric
next prev parent reply other threads:[~2025-05-30 0:19 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-28 17:00 [PATCH v4 00/13] Architecture-optimized SHA-256 library API Eric Biggers
2025-04-28 17:00 ` [PATCH v4 01/13] crypto: sha256 - support arch-optimized lib and expose through shash Eric Biggers
2025-04-30 3:48 ` Herbert Xu
2025-04-28 17:00 ` [PATCH v4 02/13] crypto: arm/sha256 - implement library instead of shash Eric Biggers
2025-04-28 17:00 ` [PATCH v4 03/13] crypto: arm64/sha256 - remove obsolete chunking logic Eric Biggers
2025-04-28 17:00 ` [PATCH v4 04/13] crypto: arm64/sha256 - implement library instead of shash Eric Biggers
2025-04-28 17:00 ` [PATCH v4 05/13] crypto: mips/sha256 " Eric Biggers
2025-04-28 17:00 ` [PATCH v4 06/13] crypto: powerpc/sha256 " Eric Biggers
2025-04-28 17:00 ` [PATCH v4 07/13] crypto: riscv/sha256 " Eric Biggers
2025-05-08 17:45 ` Palmer Dabbelt
2025-05-08 18:06 ` Eric Biggers
2025-04-28 17:00 ` [PATCH v4 08/13] crypto: s390/sha256 " Eric Biggers
2025-05-29 17:05 ` Alex Williamson
2025-05-29 17:37 ` Eric Biggers
2025-05-29 19:00 ` Eric Biggers
2025-05-29 20:14 ` Linus Torvalds
2025-05-29 21:16 ` Eric Biggers
2025-05-29 23:54 ` Linus Torvalds
2025-05-30 0:18 ` Eric Biggers [this message]
2025-06-01 23:00 ` Eric Biggers
2025-06-02 14:45 ` Linus Torvalds
2025-04-28 17:00 ` [PATCH v4 09/13] crypto: sparc - move opcodes.h into asm directory Eric Biggers
2025-04-28 17:00 ` [PATCH v4 10/13] crypto: sparc/sha256 - implement library instead of shash Eric Biggers
2025-04-28 17:00 ` [PATCH v4 11/13] crypto: x86/sha256 " Eric Biggers
2025-04-28 17:00 ` [PATCH v4 12/13] crypto: sha256 - remove sha256_base.h Eric Biggers
2025-04-28 17:00 ` [PATCH v4 13/13] crypto: lib/sha256 - improve function prototypes Eric Biggers
2025-05-05 12:24 ` [PATCH v4 00/13] Architecture-optimized SHA-256 library API Herbert Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250530001858.GD3840196@google.com \
--to=ebiggers@kernel.org \
--cc=Jason@zx2c4.com \
--cc=alex.williamson@redhat.com \
--cc=ardb@kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=sparclinux@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).