This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.
Neels Hofmeyr gerrit-no-reply at lists.osmocom.orgPatch Set 3: (2 comments) I would spend more time on this if it is deemed worthwhile. Let me know what you think ... https://gerrit.osmocom.org/#/c/6471/3//COMMIT_MSG Commit Message: Line 38: handover2 window rxlev averaging 7 > What about using a node instead of prepending the algorithm to each command I first was going to do that, then gave up on it a little because not introducing nodes took less time. If "we" prefer, I can still review it. But note that I want to keep the old 'handover foo' commands for backwards compatibility. So we could add nodes like this: network # enable handover 1 # choose algo handover algorithm 2 # algo 1 config handover1 window rxlev averaging 5 #... # algo 2 config handover2 window rxlev averaging 5 #... # and then we would also still have aliases # to be backwards compatible, aliases for handover1 handover window rxlev averaging 5 https://gerrit.osmocom.org/#/c/6471/3/src/libbsc/handover_decision.c File src/libbsc/handover_decision.c: Line 218: avg = neigh_meas_avg(nmp, ho_get_hodec1_rxlev_neigh_avg_win(bts->ho)); > I think it makes more sense to call this ho_hodec1_{get,set}_*, as it's par hodec means handover decision. So at first I had the plain ho_get_foo / ho_set_foo with all params shared across handover algos. So the variable part for naming is 'foo'. The easiest way to add different realms then is to prefix the foo part. The way you request would add the concept of another section in a more complex way. To illustrate the current patch state: the namespace currently looks like # general choice active algorithm hodec1_rxlev... hodec1_yada hodec2_rxlev... hodec2_yada The get/set functions produced in handover_cfg.h then end up the above, with 'ho_get_' and 'ho_set_' etc prefixed. We could add explicit sections like common.active common.algorithm hodec1.rxlev... hodec2.rxlev... which would make those macros a bit more complex still. BTW I also considered tossing out those macros and rather generate the C code from some templates; the advantage being that we can properly browse the produced code with ctags and similar tools, and don't need to read obscure macros... All in all, there is still polishing and perfectioning I could do here. The current patch is the easiest way to get it working, since I've already spent too much time with code structuring. I'm ready to restructure more if everyone thinks it's worthwhile. -- To view, visit https://gerrit.osmocom.org/6471 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I6475b2543b18d21710a6d774b214cb484f36ec8e Gerrit-PatchSet: 3 Gerrit-Project: osmo-bsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr <nhofmeyr at sysmocom.de> Gerrit-Reviewer: Harald Welte <laforge at gnumonks.org> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Neels Hofmeyr <nhofmeyr at sysmocom.de> Gerrit-Reviewer: Pau Espin Pedrol <pespin at sysmocom.de> Gerrit-HasComments: Yes