On Wed, 2013-05-15 at 10:17 +0200, Ard Biesheuvel wrote:
On 14 May 2013 18:49, Jon Medhurst (Tixy) tixy@linaro.org wrote:
This also enables CONFIG_CRYPTO_SHA1 which we didn't already have enabled in our builds, so I assume nothing actually needs this option. If that's true, then it doesn't seem worth enabling an optimised version of code which isn't going to be used. ;-)
Good point. However, if I use merge_config to generate eg. arndale/ubuntu, I end up with a .config which does have SHA1 and AES enabled.
I keep forgetting that some people still use ubuntu.conf, that enables the 2000+ config options used by Ubuntu for their desktop distro. We should really delete that and stick with ubuntu-minimal.conf (which I believe that Fathi was suggesting should become a generic linux disro config )
So what would be the best way to enable CONFIG_CRYPTO_SHA1_ARM automatically if some more specific config fragment enables CONFIG_CRYPTO_SHA1 (and CONFIG_ARM), even if only through implicit dependencies?
I was going to suggest we had a patch which makes CONFIG_CRYPTO_SHA1_ARM
default CONFIG_CRYPTO_SHA1
or something like that, but I see the dependency sort of goes the other way, because CRYPTO_SHA1_ARM selects CRYPTO_SHA1.
If the assembler version is always faster I would have thought that we should always have it enabled and not have it as a user visible option. Perhaps the fact that the assembler is specifically target at ARMv4 means that on ARMv7 CPUs the latest GCC's might generate better code by using newer features?
Either way, it won't hurt to enable it in Linaro kernels as it doesn't look like it is ever used, so would just add to the kernel size a bit.