diff options
author | Herbert Xu <herbert@gondor.apana.org.au> | 2006-07-30 11:53:01 +1000 |
---|---|---|
committer | Herbert Xu <herbert@gondor.apana.org.au> | 2006-09-21 11:41:50 +1000 |
commit | 6d7d684d635ac5a345f075015f2c84169c111c6a (patch) | |
tree | 9a1b397fe8db3c14cc69880aba747e50c1a1faa2 /include/linux/crypto.h | |
parent | 65b75c36f4e8422602826c75c803136e0da94122 (diff) | |
download | op-kernel-dev-6d7d684d635ac5a345f075015f2c84169c111c6a.zip op-kernel-dev-6d7d684d635ac5a345f075015f2c84169c111c6a.tar.gz |
[CRYPTO] api: Added crypto_alloc_base
Up until now all crypto transforms have been of the same type, struct
crypto_tfm, regardless of whether they are ciphers, digests, or other
types. As a result of that, we check the types at run-time before
each crypto operation.
This is rather cumbersome. We could instead use different C types for
each crypto type to ensure that the correct types are used at compile
time. That is, we would have crypto_cipher/crypto_digest instead of
just crypto_tfm. The appropriate type would then be required for the
actual operations such as crypto_digest_digest.
Now that we have the type/mask fields when looking up algorithms, it
is easy to request for an algorithm of the precise type that the user
wants. However, crypto_alloc_tfm currently does not expose these new
attributes.
This patch introduces the function crypto_alloc_base which will carry
these new parameters. It will be renamed to crypto_alloc_tfm once
all existing users have been converted.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Diffstat (limited to 'include/linux/crypto.h')
-rw-r--r-- | include/linux/crypto.h | 14 |
1 files changed, 3 insertions, 11 deletions
diff --git a/include/linux/crypto.h b/include/linux/crypto.h index 530dc4b..6847ab0 100644 --- a/include/linux/crypto.h +++ b/include/linux/crypto.h @@ -194,8 +194,8 @@ static inline int crypto_alg_available(const char *name, u32 flags) /* * Transforms: user-instantiated objects which encapsulate algorithms - * and core processing logic. Managed via crypto_alloc_tfm() and - * crypto_free_tfm(), as well as the various helpers below. + * and core processing logic. Managed via crypto_alloc_*() and + * crypto_free_*(), as well as the various helpers below. */ struct cipher_tfm { @@ -278,16 +278,8 @@ struct crypto_attr_alg { * Transform user interface. */ -/* - * crypto_alloc_tfm() will first attempt to locate an already loaded algorithm. - * If that fails and the kernel supports dynamically loadable modules, it - * will then attempt to load a module of the same name or alias. A refcount - * is grabbed on the algorithm which is then associated with the new transform. - * - * crypto_free_tfm() frees up the transform and any associated resources, - * then drops the refcount on the associated algorithm. - */ struct crypto_tfm *crypto_alloc_tfm(const char *alg_name, u32 tfm_flags); +struct crypto_tfm *crypto_alloc_base(const char *alg_name, u32 type, u32 mask); void crypto_free_tfm(struct crypto_tfm *tfm); /* |