Theodore Tso wrote:
I would suggest that the best way to do this is to *add* new mutator
functions (and accessor functions, where necessary) which applications
who care about ABI stability can use, and then document a set of
interfaces for which ABI stability is guaranteed. That could be a
relatively small set initially --- enough for applications that aren't
doing anything strange, and then this list can gradually be expanded
out, with some new ABI stable functions getting added as necessary.
Possibly. There are (or have been) analogous developments that could
contribute to your thinking of how to address LSB concerns. Eg. the FIPS
work has certification, signature-checking, and other "fixed interface"
considerations (I think, I haven't been involved in this at all). Also,
OPENSSL_NO_DEPRECATED is used as a mechanism to "nudge" away from
backwards-compatible interfaces to their preferred replacements (more of
this coming to the cvs list in a day or three, BTW). If you define this
symbol when building your code against openssl, deprecated interfaces
will not be exposed from the headers. If you define this symbol when
building openssl itself, deprecated interfaces will not be compiled (I
know this doesn't address structures/macros/etc that are not
compiled/linkable interfaces, but you get the general idea).
There appear to be a few possible avenues to explore;
* define LSB-specific wrapper libraries/interfaces to implement a stable
ABI,
* define only a small subset of functionality in LSB, with the intention
of openssl keeping *those* interfaces fixed,
* look for ways that a FIPS/NO_DEPRECATED-style pre-processor
configuration could compile openssl in some LSB-friendly manner,
* define LSB relative to an openssl "stable" branch.
The last point should perhaps not be scoffed at. This is how
compatibility is handled in the real world anyway - until openssl
reaches some kind of "v1.0" state, 0.9.7 is considered a different
library to 0.9.8, such that fixes and maintenance for each branch *do*
maintain ABI compatibility. Ie. distributions typically install distinct
shared-libraries for each, and track them with distinct packages.
Having said all that, I'll have to leave this issue to others who have
the motivation and time for it.
Cheers,
Geoff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
