On Mon, Aug 15, 2011 at 04:55:46PM +0800, Herbert Xu wrote: > 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. > I've just noticed that we need the update functionality to change the priority of algorithms that are not build from templates because we can't delete them without unloading the module. If the algorithm is not build as a module, we can't delete it at all. So there is no chance to change the priority without an update functionality. Therefore I'll bring the update functions back. I'll use your option 1) to deal with the algorithms on top of the changed one. -- 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
