On Tue, Jun 02, 2009 at 11:21:51AM +0200, Steffen Klassert wrote: > > The reason for the wrap work is to have a possibility to choose a > certain version of an algorithm as the system default. The advantage > e.g. for pcrypt is that we can turn over the whole system to pcrypt, > or we can choose for pcrypt by the algorithm name if we want to use > it just for a subset of transforms. In particular we have a possibility > to use pcrypt without touching other subsystems (like networking) and > userspace tools for now. Yes but what you're creating is a user-space API. IMHO we don't want to have ad-hoc APIs such as this scattered around the place. pcrypt is certainly not the only algorithm that needs to be able to decide whether it should serve as the system default. So what I suggest is that you make pcrypt take a higher priority for now, so that it always is the default once instantiated. After all if you instantiate it then you probably want to use it as the default. We can then work on the generic user-space API to control crypto API algorithms, in particular, allow the user to change their priorities so as to determine the system default. This has been on my todo list for years, but it has never risen to the top. What I have in mind is a netlink protocol not unlike xfrm which controls crypto algorithm properties (and queries them so we can obsolete /proc/crypto). Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
