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

[Ard Biesheuvel]

On 4 October 2013 19:48, Will Deacon <will.deacon at arm.com> wrote:

> On Thu, Oct 03, 2013 at 10:59:23PM +0100, Ard Biesheuvel wrote:
>> 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.