summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/engine/README
diff options
context:
space:
mode:
Diffstat (limited to 'src/lib/libcrypto/engine/README')
-rw-r--r--src/lib/libcrypto/engine/README4
1 files changed, 2 insertions, 2 deletions
diff --git a/src/lib/libcrypto/engine/README b/src/lib/libcrypto/engine/README
index 6b69b70f57..bc4a9041ff 100644
--- a/src/lib/libcrypto/engine/README
+++ b/src/lib/libcrypto/engine/README
@@ -122,7 +122,7 @@ use by EVP_MD code. Ditto for tb_rsa.c, tb_dsa.c, etc. These instantiations of
122ENGINE_TABLE essentially provide linker-separation of the classes so that even 122ENGINE_TABLE essentially provide linker-separation of the classes so that even
123if ENGINEs implement *all* possible algorithms, an application using only 123if ENGINEs implement *all* possible algorithms, an application using only
124EVP_CIPHER code will link at most code relating to EVP_CIPHER, tb_cipher.c, core 124EVP_CIPHER code will link at most code relating to EVP_CIPHER, tb_cipher.c, core
125ENGINE code that is independant of class, and of course the ENGINE 125ENGINE code that is independent of class, and of course the ENGINE
126implementation that the application loaded. It will *not* however link any 126implementation that the application loaded. It will *not* however link any
127class-specific ENGINE code for digests, RSA, etc nor will it bleed over into 127class-specific ENGINE code for digests, RSA, etc nor will it bleed over into
128other APIs, such as the RSA/DSA/etc library code. 128other APIs, such as the RSA/DSA/etc library code.
@@ -188,7 +188,7 @@ state will be unchanged. Thus, no cleanup is required unless registration takes
188place. ENGINE_cleanup() will simply iterate across a list of registered cleanup 188place. ENGINE_cleanup() will simply iterate across a list of registered cleanup
189callbacks calling each in turn, and will then internally delete its own storage 189callbacks calling each in turn, and will then internally delete its own storage
190(a STACK). When a cleanup callback is next registered (eg. if the cleanup() is 190(a STACK). When a cleanup callback is next registered (eg. if the cleanup() is
191part of a gracefull restart and the application wants to cleanup all state then 191part of a graceful restart and the application wants to cleanup all state then
192start again), the internal STACK storage will be freshly allocated. This is much 192start again), the internal STACK storage will be freshly allocated. This is much
193the same as the situation in the ENGINE_TABLE instantiations ... NULL is the 193the same as the situation in the ENGINE_TABLE instantiations ... NULL is the
194initialised state, so only modification operations (not queries) will cause that 194initialised state, so only modification operations (not queries) will cause that