Re: x86 asm SHA1 (draft)

The series to revamp SHA1 is good but judging the merit of each
is outside my expertise, so I'd appreciate help to evaluate
these changes.  For example, I cannot choose between competing
three implementations for ppc without having access to a variety
of ppc machines, and even if I did, ppc is not what I normally
use, so incentive to try picking the best one for everybody is
relatively low on my part.

Well, I'm not sure it's worth this much trouble.  Both of my PPC
implementations are smaller and faster than the current one,
so that's a pretty easy decision.  The difference between them
is 2-3%, which is, I think, not enough to be worth the maintenance
burden of a run-time decision infrastructure.  Just pick either one
and call it a day.

The only external interface for the set of SHA1 implementation
alternatives to the outside world is a well established SHA_CTX
type, and three functions SHA1_Init(), SHA1_Update() and
SHA1_Final(), and the alternative implementations are supposed
to be drop-in replaceable.

I'd prefer it it was an *opaque* SHA_CTX type.  Sometimes you can achieve
some useful benefits by rearranging the fields.  For example, keeping the
64-bit length field as a native-order 64-bit number when appropriate.
And sometimes it's useful to have the full 80-word W[] array, while
other implementations don't want it.

We probably would want to collect the benchmark results from
popular platforms, have a summary to help people to choose a
sensible one in the toplevel INSTALL file, and include the raw
numbers in Documentation/technical/sha1-implementations.txt.

Not that numbers are bad, but I think that until there's a real
need for more than a single good-enough version per instruction set,
this is excessive.  Does hashing even show up on a profile?