lkml.org 
[lkml]   [2003]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: crypto API and IBM z990 hardware support
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/aes.c
> crypto/arch/i386/aes.s

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
> built.

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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:46    [W:0.067 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site