X-Git-Url: https://git.openssl.org/gitweb/?p=openssl.git;a=blobdiff_plain;f=README.ENGINE;h=530a4eddb9d29a55e53dc614f6685ef5ab710ba2;hp=1412b2209267a00512dc4ed1e15ba1c231e47d68;hb=d407fd2c87aab12d6e2139f3aa79880a75efdd56;hpb=a8a1878256d4dd3318f6c828ca54924a71e3d34f

diff --git a/README.ENGINE b/README.ENGINE
index 1412b22092..530a4eddb9 100644
--- a/README.ENGINE
+++ b/README.ENGINE
@@ -6,18 +6,17 @@
   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.
 
   There are currently built-in ENGINE implementations for the following
   crypto devices:
 
-      o CryptoSwift
-      o Compaq Atalla
+      o Cryptodev
+      o Microsoft CryptoAPI
+      o VIA Padlock
       o nCipher CHIL
-      o Nuron
-      o Broadcom uBSec
 
   In addition, dynamic binding to external ENGINE implementations is now
   provided by a special ENGINE called "dynamic". See the "DYNAMIC ENGINE"
@@ -139,7 +138,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 +153,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 +173,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 +183,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 +191,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 +207,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 +229,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 +242,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 +281,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.