> Hello James,
> I'm currently looking at the crypto API and considering adding support for
> new hardware instructions implemented in the IBM z990 architecture. Since I
> found your name in most of the files I find it appropriate to ask for your
> opinion on how to integrate the new code (from a design point of view).
> z990 provides hardware support for AES, DES and SHA. The problem is, that
> the respective instructions might not be implemented on all z990 systems
> (export restrictions etc). Hence, a check must be run to test whether the
> instruction set is present, and if not, a fall-back to the current software
> implementation must be taken.
Are there any details available on how all of this is implemented? Are
these instructions synchronous?
> I basically have two solutions in mind: (1)
> to integrate the new code into the current crypto files; add some #ifdef s
> to prevent the code from being compiled when building a non-z990 kernel;
> add some ifs for runtime check.
No, the core crypto code should not be altered with #ifdefs to handle some
arch specific issue.
> (2) include the new code into an arch/s390/crypto directory. The
> advantage of (1) is that there are no seperate crypto directories, the
> code doesn't drift apart. Furthermore, it's probably the best solution
> with respect to the kernel module loader. On the other hand, the
> hardware support is very arch-specific, which would fit in option (2).
> (2) however has the disadvantage that there are multiple crypto modules;
> the user has to select one to load -> must have different names for one
> algorithm. What is your opinion on this subject?
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:
where on i386, aes.s would be built into aes.o and aes.c would not be
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.
-- James Morris <email@example.com>
- 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/