> OK, attached is a patch against CVS mainline. For me it works in both > static and shared versions.
Cool, I'll try to take a look in the next few days. > I didn't get it, sorry. Should I make the Padlock support always static > as is the cryptodev? The PadLock is available on new VIA Nehemiah CPUs > and if present (and successfully detected by the Padlock engine > initialization routine) it should be used, yes. But that's the same > situation as with other engines, isn't it? Not necessarily - I am still unsure of whether we should attempt to automatically probe shared-lib engines during ENGINE_load_builtin_engines(). Right now, no shared-lib engines will be available unless they're loaded or specified by id, so you'd automatically fall back to the default software implementations. I could go with compiling the padlock engine statically a la cryptodev iff we can ensure that it is only compiled on supported platforms. The reason we can "compile-in" cryptodev is that it becomes a NOP except on openbsd and any other platform that supports cryptodev or is prepared to accept the additional overhead even if it isn't supported. I don't think a large class of x86 platform targets would accept such a situation with the padlock stuff given that the majority of run-time environments wouldn't be able to use it. Is there anything else specific about "padlock-capable" systems that could be used to set specific targets for this stuff? Cheers, Geoff -- Geoff Thorpe, RT/openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
