On Mon, Jan 02, 2006 at 06:57:59PM +0100, Andy Polyakov wrote: > So let's make it a vote. > > 1. Should there be or not option for built-in engine in shared library > context, or should all engines without exclusion be available as > loadable modules? > > My vote is "there should be an option for built-in engines even in > shared context." > > 2. If consensus is "yes for the option," which engines should be > available as builtins? Popular ones? Small ones? Self-contained ones? > Those addressing specific CPU capabilities directly? Those packager > wishes to favor? Those we decide on per-engine basis? > > My vote is "per-engine basis based primarily on self-contained criteria > [i.e. when engine can operate without additional [user-land] component > provided by 3rd party, where 1st and 2nd parties are OS provider and > OpenSSL]." A.
I think we first need to start with why do we have loadable modules. I can see a few reasons for this: - 3rd party engines can be added and loaded. And I think this is the most important one. And this would even be useful in case the library is build/linked staticly. - Reduces the size of the library, which might for instance be important for embedded applications. But if size is important they should try and disable things they don't need in the first place. Anything else? I think that having build in eniges in a shared library can make perfect sense. I currently don't see a good reason why all those modules are external while they could be internal. I wondering what you mean with "3rd party". For instance, there now seems to be a gmp engine (which is disabled by default). It would seem that your definition would mean it required something 3rd party. I don't see why that would be different from the others. Or are you talking about something else? The gmp engine seems to be disabled, yet it gets build as a shared module, but doesn't have any code in it. I don't think it's useful that a module gets created for that, since I can't do a thing with it. Kurt ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
