On Fri, 12 Jan 2007, Thor Lancelot Simon wrote:
> And that is why, as I noted yesterday, a separate opencrypto "driver"
> for this functionality really doesn't seem right.  I would urge you,
> again, to simply add support for these instructions to the code in
> /sys/crypto and merge it with the code in /sys/opencrypto that is the
> algorithm implementations used by the existing opencrypto software
> backend.

It feels wrong - there is a subsystem that provides useful abstraction for 
cryptography, where cryptosoft is just one "provider" that can register 
itself. Doesn't mixing xcrypt instructions sacrifice that abstraction?

> If you do that, _everything_ in the kernel that uses crypto wins.
> If you do what you did, only things that already know how to use
> opencrypto (basically nothing but fast_ipsec, since there is already
> a better openssl engine for these cards than cryptodev) win...

It seems better to me to adjust things like cgd to use opencrypto. The 
other way around only people with PadLock CPUs will win, but machines with 
hifn and ubsec will still be stuck with cryptosoft.

-- Daniel