Skip to contentSkip to conversation

crypto/api.c: crypto_alg_available(): flags param not used.

PATCH In review Kausty 4 participants 4 messages Jan 20, 2005 – Oct 31, 2005

Subsystems (4)
Networking Network drivers Crypto API Networking IPsec
lore
Share & tools
lore

Kausty

author
#0 lore raw

hi
A small observation. In crypto/api.c in linux-2.6.8.1

The function:
int crypto_alg_available(const char *name, u32 flags)

has a flags param which does not seem to be used.

though it does not matter much but has this been fixed in later releases? xfrm functions in ipsec do call this function but always with flags as 0.

Thanks and regards
kausty

(sorry... not subscribed to this list, pls CC if any valuable info)

#1 lore raw
Quoted 6 lines · Kausty

hi
A small observation. In crypto/api.c in linux-2.6.8.1

The function:
int crypto_alg_available(const char *name, u32 flags)

Quoted 7 lines

has a flags param which does not seem to be used.

though it does not matter much but has this been fixed in later releases? xfrm functions in ipsec do call this function but always with flags as 0.

Thanks and regards
kausty

IIRC, this was to allow future code to specify preferences for the type of algorithm driver (e.g. hardware), but has not been used. This is an example of why it's a bad idea to add infrastructure which isn't being used at the time.

- James

Signature · 2 lines
James Morris
<[email protected]>
#2 lore raw

PATCH 1/1 crypto/api.c: remove the second argument of crypto_alg_available()

Quoted 13 lines · James Morris
Quoted 11 lines · Kausty

hi
A small observation. In crypto/api.c in linux-2.6.8.1

The function:
int crypto_alg_available(const char *name, u32 flags)

has a flags param which does not seem to be used.

though it does not matter much but has this been fixed in later releases? xfrm functions in ipsec do call this function but always with flags as 0.

Quoted 7 lines
Quoted 2 lines

Thanks and regards
kausty

IIRC, this was to allow future code to specify preferences for the type of algorithm driver (e.g. hardware), but has not been used. This is an example of why it's a bad idea to add infrastructure which isn't being used at the time.

Since it's still unused, a patch to remove this second argument is below.

Quoted 1 line

- James

cu
Adrian

<-- snip -->

The second argument of crypto_alg_available() was not used and is therefore removed in this patch.

Signed-off-by Adrian Bunk <[email protected]>

---

 crypto/api.c           |    2 +-
 crypto/tcrypt.c        |    2 +-
 drivers/net/ppp_mppe.c |    4 ++--
 include/linux/crypto.h |    4 ++--
 net/xfrm/xfrm_algo.c   |    8 ++++----
 5 files changed, 10 insertions(+), 10 deletions(-)
include/linux/crypto.h renamed from include/linux/crypto.h.old +2 -2
@@ -152,9 +152,9 @@
  * Algorithm query interface.
  */
 #ifdef CONFIG_CRYPTO
-int crypto_alg_available(const char *name, u32 flags);
+int crypto_alg_available(const char *name);
 #else
-static inline int crypto_alg_available(const char *name, u32 flags)
+static inline int crypto_alg_available(const char *name)
 {
 	return 0;
 }
crypto/api.c renamed from crypto/api.c.old +1 -1
@@ -300,7 +300,7 @@
 	return ret;
 }
 
-int crypto_alg_available(const char *name, u32 flags)
+int crypto_alg_available(const char *name)
 {
 	int ret = 0;
 	struct crypto_alg *alg = crypto_alg_mod_lookup(name);
crypto/tcrypt.c renamed from crypto/tcrypt.c.old +1 -1
@@ -753,7 +753,7 @@
 
 	while (*name) {
 		printk("alg %s ", *name);
-		printk((crypto_alg_available(*name, 0)) ?
+		printk((crypto_alg_available(*name)) ?
 			"found\n" : "not found\n");
 		name++;
 	}
drivers/net/ppp_mppe.c renamed from drivers/net/ppp_mppe.c.old +2 -2
@@ -695,8 +695,8 @@
 static int __init ppp_mppe_init(void)
 {
 	int answer;
-	if (!(crypto_alg_available("arc4", 0) &&
-	      crypto_alg_available("sha1", 0)))
+	if (!(crypto_alg_available("arc4") &&
+	      crypto_alg_available("sha1")))
 		return -ENODEV;
 
 	sha_pad = kmalloc(sizeof(struct sha_pad), GFP_KERNEL);
net/xfrm/xfrm_algo.c renamed from net/xfrm/xfrm_algo.c.old +4 -4
@@ -369,7 +369,7 @@
 		if (!probe)
 			break;
 
-		status = crypto_alg_available(name, 0);
+		status = crypto_alg_available(name);
 		if (!status)
 			break;
 

@@ -428,19 +428,19 @@
 	BUG_ON(in_softirq());
 
 	for (i = 0; i < aalg_entries(); i++) {
-		status = crypto_alg_available(aalg_list[i].name, 0);
+		status = crypto_alg_available(aalg_list[i].name);
 		if (aalg_list[i].available != status)
 			aalg_list[i].available = status;
 	}
 	
 	for (i = 0; i < ealg_entries(); i++) {
-		status = crypto_alg_available(ealg_list[i].name, 0);
+		status = crypto_alg_available(ealg_list[i].name);
 		if (ealg_list[i].available != status)
 			ealg_list[i].available = status;
 	}
 	
 	for (i = 0; i < calg_entries(); i++) {
-		status = crypto_alg_available(calg_list[i].name, 0);
+		status = crypto_alg_available(calg_list[i].name);
 		if (calg_list[i].available != status)
 			calg_list[i].available = status;
 	}
maintainer
#3 lore raw

Re: [2.6 patch] crypto/api.c: remove the second argument of crypto_alg_available()

Quoted 8 lines · Adrian Bunk
Quoted 5 lines

IIRC, this was to allow future code to specify preferences for the type of algorithm driver (e.g. hardware), but has not been used. This is an example of why it's a bad idea to add infrastructure which isn't being used at the time.

Since it's still unused, a patch to remove this second argument is below.

I'll be using this field very soon to indicate that the caller intends to find synchronous algorithms only as opposed to either synchronous or asynchronous. So I'd like to keep it for now.

Thanks,

Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt