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.org
Patch 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