[PATCH v2 0/3] ARM: NEON based fast(er) AES in CBC/CTR/XTS modes

On 4 October 2013 19:48, Will Deacon [off-list ref] wrote:

On Thu, Oct 03, 2013 at 10:59:23PM +0100, Ard Biesheuvel wrote:

quoted

Note to reviewers:
Reviewing the file aesbs-core.S may be a bit overwhelming, so if there are any
questions or concerns, please refer the file bsaes-armv7.pl which can be found
at the link below. This is the original Perl script that gets called by
OpenSSL's build system during their build to generate the .S file on the fly.
[In the case of OpenSSL, this is used in some cases to target different
assemblers or ABIs]. This arrangement is not suitable (or required) for the
kernel, so I have taken the generated .S file instead.

    http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=6f6a6130

This series still depends on commit a62b01cd (crypto: create generic version of
ablk_helper) which I omitted this time but which can be found in the cryptodev
tree or in linux-next.

Why do you consider it unsuitable to ship the perl script with the kernel?
Perl 5 is already documented as a build dependency in Documentation/Changes
and I'd *much* rather the .S file was generated rather than shipped and
hacked. That amount of opaque assembly code for something like crypto feels really
dangerous from both a review and a maintenance perspective.

First of all, please note that the whole point of working so closely
with the OpenSSL maintainer on this is that the version I am
presenting here is the verbatim output of the Perl script that lives
in the OpenSSL tree. So just shipped, not shipped and hacked.

Personally, I would much prefer merging the .pl file as well, I just
thought (and I did poll some people informally) that this is not
something most people are happy about. If I am wrong about this, than
I am quite happy to respin so the .S is generated on the fly.

-- 
Ard.