On Mon, 18 Feb 2019 11:17:45 +0100, Matt Caswell wrote: > At the moment OPENSSL_CTX is implemented using CRYPTO_EX_DATA. An alternative > implementation approach would be that the struct is internally transparent and > is just a bucket of stuff (without using CRYPTO_EX at all). I guess the reason > for doing so would be performance (to reduce the indirection of going via > CRYPTO_EX).
The central idea here is that OPENSSL_CTX is a bag of "stuff" and that each sub-system should decide on their own what its "stuff" is. Of course, the bag could have been made like a structure with specific pointers for each sub-system that wants to store something, but I find that approach a bit messy, as the sub-systems become less self contained, and also have less control over their own "stuff". For example, if there's a need for a lock to retrieve some data, does everyone else have to learn to use that lock, and what happens if someone forgets, i.e. how error prone can it become? As an alternative, if the sub-system defines its own internal API for access of stuff, that does all the needed locking, why does everyone else need to know exactly how it's stored in the library context? The reason why I chose CRYPTO_EX_DATA for internal storage? I was actually about to implement a generic "bag", when I realised that we already have that in CRYPTO_EX_DATA. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/