On Mon, Aug 15, 2011 at 10:02:57AM +0200, Steffen Klassert wrote: > > I don't think it is broken. It's just easier to handle if an underlying > algorithm changes it's priority. If the user changes the priority of a > certain algorithm, I take the difference of the old and new priority > value and add this to all subsequent algorithms. So this can not take the > weight into account without some 'per algorithm' priority update functions. Oh I see. I don't think we need to go that far. Here are two simpler ways of handling this: 1) Liquidate all instances on top of the algorithm being changed (this is what we already do when you register a new implementation of an algorithm with a higher priority). 2) Do nothing and let the user change everything manually. My take would be to just do 1) considering that the usage scenario is that the user is either going to change something like AES at the very bottom of the pile or something complex at the top. Cheers, -- Email: Herbert Xu <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
