On Wed, Jul 02, 2003 at 07:35:16PM +1000, James Morris wrote:
> The plan is to provide crypto/arch/ subdirectories where arch optimized
> versions of the crypto algorithms are implemented, and built automatically
> (via configuration defaults) instead of the generic C versions.
> So, there might be:
crypto/arch/ sounds like a bad idea. We really should avoid arch code
outside arch/ and include/asm*. So arch/<foo>/crypto/ as suggested by
Thomas is much better.
> where on i386, aes.s would be built into aes.o and aes.c would not be
That's a really bad idea. Think of a i586/i686 optimized assembler
implementaion e.g. using MMX or SSE or whatever. You'll always need
the generic version as fallback.
> The simple solution for you might be something like:
> crypto/aes.c -> aes.o
> crypto/arch/s390/aes_z990.c -> aes_z990.o
> and the administrator of the system could configure modprobe.conf to alias
> aes to aes_z990 if the latter is supported in hardware.
Right. And IMHO this should happen with all optimized version - putting
policy in the kernel to select them sounds like a bad idea, especially
as it could get rather complicated when it involves multiple optimized
and / or hardware implementations.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 07 2003 - 22:00:28 EST