[PATCHv3 10/10] x86/crypto: add pclmul acceleration for crc64
Keith Busch
kbusch at kernel.org
Tue Feb 22 12:51:16 PST 2022
On Tue, Feb 22, 2022 at 12:06:39PM -0800, Eric Biggers wrote:
> Is the license of that code compatible with the kernel's license?
It's released into "public domain", so I assume we can leverage it into
GPL licenced code. I don't have similar past experiences with this
scenario, so please correct me if I'm mistaken.
> In any case, adding uncommented generated assembly isn't acceptable. The most
> common convention for Linux kernel crypto is to use hand-written assembly that
> is properly commented.
>
> There is some precedent for using compiler intrinsics instead, e.g.
> crypto/aegis128-neon-inner.c. (I'm not sure why they aren't used more often.)
>
> There are also some files where a Perl script generates the assembly code.
> (This is a bit ugly IMO, but it's what the author of much of OpenSSL's crypto
> assembly code does, and it was desired to reuse that code.)
>
> Anyway, those are the available options. Checking in some uncommented generated
> assembly isn't one of them.
Fair enough. I'll find help from someone to author an appropriate form
to replace this patch.
More information about the Linux-nvme
mailing list