NOTES, THOUGHTS, and EVERYTHING
-------------------------------
(1) Concurrency and locking ... I made a change to the ENGINE_free code
because I spotted a potential hold-up in proceedings (doing too
much inside a lock including calling a callback), there may be
other bits like this. What do the speed/optimisation freaks think
of this aspect of the code and design? There's lots of locking for
manipulation functions and I need that to keep things nice and
solid, but this manipulation is mostly (de)initialisation, I would
think that most run-time locking is purely in the ENGINE_init and
ENGINE_finish calls that might be made when getting handles for
RSA (and friends') structures. These would be mostly reference
count operations as the functional references should always be 1
or greater at run-time to prevent init/deinit thrashing.
(2) nCipher support, via the HWCryptoHook API, is now in the code.
Apparently this hasn't been tested too much yet, but it looks
good. :-) Atalla support has been added too, but shares a lot in
common with Ben's original hooks in bn_exp.c (although it has been
ENGINE-ified, and error handling wrapped around it) and it's also
had some low-volume testing, so it should be usable.
(3) Of more concern, we need to work out (a) how to put together usable
RAND_METHODs for units that just have one "get n or less random
bytes" function, (b) we also need to determine how to hook the code
in crypto/rand/ to use the ENGINE defaults in a way similar to what
has been done in crypto/rsa/, crypto/dsa/, etc.
(4) ENGINE should really grow to encompass more than 3 public key
algorithms and randomness gathering. The structure/data level of
the engine code is hidden from code outside the crypto/engine/
directory so change shouldn't be too viral. More important though
is how things should evolve ... this needs thought and discussion.
64c4f5732d