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.
