Am Donnerstag, 10. September 2015, 17:04:31 schrieb Tim Chen:
Hi Tim,
Is there a scenario you can think of
when a lower performing sha1 transform needs to
be exposed as a separate driver?
My immediate concern is testing: it is hard to test the individual
implementations.
Otherwise the glue code logic will only expose the
best performing one for a cpu and hide the others, which was intentional
on our part to prevent a lower performing sha from getting used.
Agreed, but the kernel crypto API does that already using the priorities --
IMHO a very clean and easy to interpret solution.
Furthermore, if somebody really has a need to not use the fastest HW
implementation, the kernel crypto API allows him to do that. With the hard-
wired approach in the glue file, you are stuck.
Ciao
Stephan