bignum: allow concurrent BN_MONT_CTX_set_locked()

[openssl.git] / README.ENGINE

diff --git a/README.ENGINE b/README.ENGINE
index 1412b2209267a00512dc4ed1e15ba1c231e47d68..0ff8333709305d2a0ff84864aec1e22043701a4d 100644 (file)
--- a/README.ENGINE
+++ b/README.ENGINE
@@ -6,7 +6,7 @@
   crypto devices (eg. accelerator cards). This component is called ENGINE,
   and its presence in OpenSSL 0.9.6 (and subsequent bug-fix releases)
   caused a little confusion as 0.9.6** releases were rolled in two
-  versions, a "standard" and an "engine" verion. In development for 0.9.7,
+  versions, a "standard" and an "engine" version. In development for 0.9.7,
   the ENGINE code has been merged into the main branch and will be present
   in the standard releases from 0.9.7 forwards.
 
@@ -139,7 +139,7 @@
     gets its own copy of it. As such, multi-threaded code (or code that
     multiplexes multiple uses of 'dynamic' in a single application in any
     way at all) does not get confused by 'dynamic' being used to do many
-    independant things. Other ENGINEs typically don't do this so there is
+    independent things. Other ENGINEs typically don't do this so there is
     only ever 1 ENGINE structure of its type (and reference counts are used
     to keep order). The dynamic ENGINE itself provides absolutely no
     cryptographic functionality, and any attempt to "initialise" the ENGINE
@@ -154,7 +154,7 @@
     shared-library that contains the ENGINE implementation, and "NO_VCHECK"
     might possibly be useful if there is a minor version conflict and you
     (or a vendor helpdesk) is convinced you can safely ignore it.
-    "ENGINE_ID" is probably only needed if a shared-library implements
+    "ID" is probably only needed if a shared-library implements
     multiple ENGINEs, but if you know the engine id you expect to be using,
     it doesn't hurt to specify it (and this provides a sanity check if
     nothing else). "LIST_ADD" is only required if you actually wish the
@@ -174,7 +174,7 @@
 
        ENGINE *e = ENGINE_by_id("dynamic");
        ENGINE_ctrl_cmd_string(e, "SO_PATH", "/lib/libfoo.so", 0);
-       ENGINE_ctrl_cmd_string(e, "ENGINE_ID", "foo", 0);
+       ENGINE_ctrl_cmd_string(e, "ID", "foo", 0);
        ENGINE_ctrl_cmd_string(e, "LOAD", NULL, 0);
        ENGINE_ctrl_cmd_string(e, "CMD_FOO", "some input data", 0);
 
@@ -184,7 +184,7 @@
 
        openssl engine dynamic \
                  -pre SO_PATH:/lib/libfoo.so \
-                 -pre ENGINE_ID:foo \
+                 -pre ID:foo \
                  -pre LOAD \
                  -pre "CMD_FOO:some input data"
 
@@ -192,7 +192,7 @@
 
        openssl engine -vvvv dynamic \
                  -pre SO_PATH:/lib/libfoo.so \
-                 -pre ENGINE_ID:foo \
+                 -pre ID:foo \
                  -pre LOAD
 
     Applications that support the ENGINE API and more specifically, the
@@ -208,7 +208,7 @@
     "-pre" syntax in the "openssl engine" utility is that some commands
     might be issued to an ENGINE *after* it has been initialised for use.
     Eg. if an ENGINE implementation requires a smart-card to be inserted
-    during intialisation (or a PIN to be typed, or whatever), there may be
+    during initialisation (or a PIN to be typed, or whatever), there may be
     a control command you can issue afterwards to "forget" the smart-card
     so that additional initialisation is no longer possible. In
     applications such as web-servers, where potentially volatile code may
@@ -230,8 +230,8 @@
     hand such applications would only have the memory footprint of any
     ENGINEs explicitly loaded using user/admin provided control commands.
     The main advantage of not statically linking ENGINEs and only using
-    "dynamic" for hardare support is that any installation using no
-    "external" ENGINE suffers no unecessary memory footprint from unused
+    "dynamic" for hardware support is that any installation using no
+    "external" ENGINE suffers no unnecessary memory footprint from unused
     ENGINEs. Likewise, installations that do require an ENGINE incur the
     overheads from only *that* ENGINE once it has been loaded.
 
@@ -243,7 +243,7 @@
     if OpenSSL itself is built as a shared library. The instructions are
     the same in each case, but in the former (statically linked any
     dependencies on OpenSSL) you must ensure OpenSSL is built with
-    position-independant code ("PIC"). The default OpenSSL compilation may
+    position-independent code ("PIC"). The default OpenSSL compilation may
     already specify the relevant flags to do this, but you should consult
     with your compiler documentation if you are in any doubt.
 
@@ -282,7 +282,7 @@
   PROBLEMS
   ========
 
-  It seems like the ENGINE part doesn't work too well with Cryptoswift on Win32.
+  It seems like the ENGINE part doesn't work too well with CryptoSwift on Win32.
   A quick test done right before the release showed that trying "openssl speed
   -engine cswift" generated errors. If the DSO gets enabled, an attempt is made
   to write at memory address 0x00000002.