osmo-bsc[master]: HO: cfg: separate hodec1 from hodec2 parameters

Neels Hofmeyr gerrit-no-reply at lists.osmocom.org
Sat Feb 17 13:30:24 UTC 2018


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


More information about the gerrit-log mailing list