> 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? - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html