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). Hm, I thought about that already. But in this case, we can change the priority just if all the algorithms on top are unused. My intention was to be able to change the priority without the need of removing all transforms build from these algorithms. So I had the hope to get it that all existing transforms continue to use the old algorithm of hightest priority and all newly build transforms use the new algorithm with the highest priority. > > 2) Do nothing and let the user change everything manually. This has the same issue, with the only difference that the user has to remove the instances on top manually. I think the only value of the priority update is, if we can do it without removing existing transforms. If this is not possible it is much easier to just delete the algorithm in question and to build a new one with the updated priority. -- 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
