Attention is currently required from: arehbein.
Patch set 5:-Code-Review
5 comments:
File src/osmo-bsc/neighbor_ident_ctrl.c:
Patch Set #3, Line 118: llist_for_each_entry(n, &bts->neighbors, entry) {
Hmm alright. […]
I see what you mean now, "neighbor-bts" prefix means only those added by its bts_nr.
Indeed then maybe filter out by neighbor->type == NEIGHBOR_TYPE_BTS_NR here.
I think it may be a good idea that you reach the user and ask him for these details, since the provided example doesn't show up this kind of details.
Sorry for all the discussions here, all the neighbor stuff is always a bit confusing since there are many options.
File src/osmo-bsc/neighbor_ident_ctrl.c:
Patch Set #5, Line 113: cmd->reply = "bts not found.";
I don't see the error lines in other functions using a dot at the end. Let's try to be consistent (I know sometimes we aren't ;)
Patch Set #5, Line 119: if (resolve_local_neighbor(&neighbor_bts, bts, n)) {
Better check against "< 0" here, as usual for system programming and error codes, it's clearer. Otherwise I had to look whether this returned a pointer.
Patch Set #5, Line 120: LOGP(DCTRL, LOGL_ERROR, "Error resolving neighbor entry for BTS %" PRIu8 ".\n", bts->nr);
I wouldn't log an error here, it is expected that some neighbors are remote (BTS under another BSSC), and hence it is expected that some neighbor_bts may not be found. see resolve_neighbors() as an example.
File tests/ctrl_test_runner.py:
Patch Set #5, Line 630: self.assertEqual(r['value'], None)
Shouldn't this be an empty string? Or is None simply somehow converted to an empty string?
To view, visit change 30982. To unsubscribe, or for help writing mail filters, visit settings.