> If you want this in the mainstream code, you'll need to detect the > capability at runtime and use your alternate code paths only if the > hardware is present.
He did. It wouldn't work on Win64, but on Unix detection would actually work. > There are advantages in this being present all the time/dynamically enabled > if it can be done, most users/OS vendors wouldn't bother to configure an > engine backend anyway. > > I'll disagree with Andy on that aspect only. The engine modules aren't > particularly useful for this situation where the function is inherent in > some subset of CPU's, the engines will only get used by a few end users > that can be bothered to configure them. As mentioned, in order to fully utilize the pipelined architecture one would have to implement a number of mode-specific subroutines, most notably Nx-interleaved and non-interleaved for short input and tail processing, and wrap them in specific C logic. Putting this all this in general purpose code serves no purpose. Of course one could argue that improvement by patching single block function would be impressive enough, ~4x(?), but why stop there if you can reach for ~20x? This is my main argument for engine. > I doubt the OS vendors would bother > to enable an engine by default, testing of the possible configurations is > expensive and the costs of support calls if they mess up makes > autodetecting the engine to use a very unattractive proposition. One can discuss loading selected engines by default, i.e. you'd have to work to not load it:-) Then it wouldn't be any different, yet provide proper isolation for specific pipeline-enabling logic, would it? Either way, there were more points:-) A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
