On Mon, Apr 27, 2009 at 04:53:46PM +0800, Herbert Xu wrote: > > While this should work for pcrypt, I'd like this to be solved > more generally. The crux of the issue is that we can't specify > an arbitrary implementation of a given algorithm. So the obvious > solution is to specify the driver name along with the algorithm > name. So how general should it be? For the moment I would see pcrypt and maybe cryptd as possible candidates to use this mechanism. I'm just wondering if it is worth to set up a list of crypto templates that can be choosen from userspace, similar to the xfrm_algo_list. > > This is in fact pretty much what you've done, but I'd just like > it to be generalised. In particular, instead of having just a > single name per SA, we should allow one to be set for each algorithm > type. Just to get you right, do you think about adding a netlink attribute for each algorithm type? > > On another note, I don't expect this to be the primary mechanism > for activating parallel processing. Doing it manually on each > SA is just painful. This should be used for testing or when you > want to specify it for a subset of SAs only. > > When the admin wants to turn the entire system over to pcrypt, > it should be done at the crypto layer, by simply registering > the pcrypt version of the algorithm in question, and having it > as the default implementation of that algorithm. That's not really clear to me how to let the user register the pcrypt version of the algorithm, so what's the desired way do this. > > In fact, this mechanism should then be able to allow specific > SAs to not use parallel processing, which means that it should > definitely not be called accl :) > Yes, I think I'll find a better name :) Steffen -- 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
