spend time to properly separate handover 2?

I'm on the load-based handover patches: it is adding a second handover decision algorithm. What keeps slightly itching me about it is that it is not really cleanly separate from the first (current) handover algorithm. - For example, in the VTY, we have the 'handover algorithm (1|2)' command, and the 'handover *' namespace is shared between ho 1 and ho 2. So when I look at the VTY commands under 'handover', a considerable number of those apply only to handover algorithm 2, while some, like rxlev averaging window settings and similar, apply to both. (I marked the ho2 ones in the VTY docs, but still) - The patches also add penalty timers and ho failure counters in generic places. In ho algorithm 2, these penalty timers and failure counts are heeded and cause ho / assignment to be omitted if appropriate. Not so in ho1. The point being, if we add a third, fourth, fifth HO algo at some point, this would probably become a tad intransparent. I wonder now whether I should spend time on jolly's patches to more cleanly separate the two algorithms. For example, in the structs and code, more clearly set and apply the penalty timers and failure counts *only* if ho algo 2 is actually used, probably even moving all of it out to context structs only known within the ho2 code. (Otherwise, some code adds penalty timers which might never be looked at or cleaned up until the conn is discarded..) On the other hand, some shared concepts make sense to be re-used. If HO algo 3 (hypothetically) wants penalty timers as well, will separating merely amount to code dup? Do we want separate sets of parameters for ho1 and ho2? For example, for the rxlev window averaging, is it better to have one setting used for both ho1 and ho2, or do I expect each algo to remember its own rxlev averaging settings? The current patch state kind of throws both in one pot; I tried to put some struct members in a { }ho2 sub-struct, but it's a bit half-hearted. I'm deciding back and forth. Truly modularizing all of it would make for more code, like opaque struct pointers to store context, specific to each ho algorithm, at e.g. subscr_conn; and function callbacks to take actions in certain triggers (like setting a penalty timer for ho failure); fully separate VTY namespaces for each algo. In other words, a proper API, sort of like the auth algo code does. It is easier to just patch it all in there and re-use existing members, but will that bite us in the future... Any thoughts? ~N