With the userland runtime linker we can have multiple variants of a
library that are selected based on $HWCAP.
In the kernel part of crypto framework we have a need to have different
implementations of algorithms based on the cpu capabilities. Currently
we have done this in two ways.
For SPARC we are (ab)using $PLATFORM to do this, but that means that
symlinks need to be updated for every new platform even if the cpu stays
the same. This has actually turned out to be useful though because
sometimes we have needed to distinguish between an UltraSPARC II and
UltraSPARC III (and later) CPU which have the same hardware capabitlies
but different cache sizes.
For x86 our only case we have integrated so far is for using SSE and we
have a runtime check for that since this was one of the very first SSE
consumers on Solaris.
The VIA processors have hardware crypto in them. The current
development in this area is developing this as a hardware driver for the
crypto framework but it might actually make more sense to just have it
as a $HWCAP variant of the software aes module.
What we would like to be able to do is something like what we have in
userland with $HWCAP, for example:
/kernel/crypto/aes/aes_hwcap1
/kernel/crypto/aes/aes_hwcap2 [VIA_C7]
/kernel/crypto/rsa/rsa_hwcap1
/kernel/crypto/rsa/rsa_hwcap2 [SSE MMX CMOV SEP FPU]
Would this be possible to have implemented with krtld ? Or is there a
better/existing way to provide $HWCAP like functionality for kernel
modules ?
--
Darren J Moffat
