On Wed, 2013-05-15 at 10:17 +0200, Ard Biesheuvel wrote: > On 14 May 2013 18:49, Jon Medhurst (Tixy) <t...@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. -- Tixy _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
