Re: [RFC][PATCH] Make cryptoapi non-optional?

["David S. Miller" <davem@redhat.com>]

On Sat, 9 Aug 2003 14:46:27 -0500
Matt Mackall <mpm@selenic.com> wrote:

> On Sat, Aug 09, 2003 at 10:39:10AM -0700, David S. Miller wrote:
> > All of this analysis nearly requires a working implementation so
> > someone can do a code-size and performance comparison between
> > the two cases.  I know this is what you're trying to avoid, having
> > to code up what might be just thrown away :(
> 
> Ok, can I export some more cryptoapi primitives?
> 
>   __crypto_lookup_alg(const char *name);
>   __crypto_alg_tfm_size(const char *name);
>   __crypto_setup_tfm(struct crypto_alg *alg, char *buf, int size, int flags);
>   __crypto_exit_ops(...)
>   __crypto_alg_put(...);

No, this eliminates the whole point of all the abstractions.
Please just use the APIs properly.

> This would let me do alg lookup in my init and avoid the dynamic
> allocation sleeping and performance hits.

How about allocating the tfm(s) (one per cpu on SMP) at module
init time?  That's how I would implement this.

Please try to implement something using the existing APIs.

It's not the size of the cryptoapi core that I'm worries about
(that's only like 1K or 2K on 32-bit systems), it's the SHA1/MD*
code which is a bit  larger.  This might all cancel out once the
SHA1/MD* code is deleted from random.o, and your implementation
will prove/disprove this, and then we can move onto perf analysis.

> Also, I posted to cryptoapi-devel that I need a way to disable the
> unconditional padding on the hash functions.

James, comments?