neels has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bsc/+/14768 )
Change subject: add vty 'no neighbors' to remove all HO targets ...................................................................... Patch Set 1: (5 comments) https://gerrit.osmocom.org/#/c/14768/1/src/osmo-bsc/neighbor_ident_vty.c File src/osmo-bsc/neighbor_ident_vty.c: https://gerrit.osmocom.org/#/c/14768/1/src/osmo-bsc/neighbor_ident_vty.c@392 PS1, Line 392: static int del_all(struct vty *vty) > let's make this a bit more descriptive like neighbor_del_all, neigh_del_all, > bts_remove_all_neighbor […] I figured since it's in the static context, the short name would do. But indeed, in other places I argued for longer names. so ack. https://gerrit.osmocom.org/#/c/14768/1/src/osmo-bsc/neighbor_ident_vty.c@403 PS1, Line 403: if (!bts) { : vty_out(vty, "%% Error: cannot remove BTS neighbor, no BTS on this node%s", : VTY_NEWLINE); : return CMD_WARNING; : } > it's arguable whether the removal of 0 neighbors is successful or an error > (warning esentially is th […] This comment applies below. This here is more like another assert error: on a vty node that has a NULL vty->index where a BTS pointer would be expected. https://gerrit.osmocom.org/#/c/14768/1/src/osmo-bsc/neighbor_ident_vty.c@410 PS1, Line 410: while (1) { : struct gsm_bts_ref *neigh = llist_first_entry_or_null(&bts->local_neighbors, struct gsm_bts_ref, entry); > why are we not using llist_for_each_entry() here? It seems more natural to > me. […] This is a style bikeshed... Since this aims at removing *all* items, I preferred a while() loop: it doesn't need two gsm_bts_ref variables (for llist_for_each_entry_safe) to be declared outside of the loop scope. The exit conditions are sane, no danger of infinite loops. We also have other such while() loops which are arguably even safer than llist_for_each_entry_safe() -- not in this case, but generally if more than one item could be removed per iteration. https://gerrit.osmocom.org/#/c/14768/1/src/osmo-bsc/neighbor_ident_vty.c@432 PS1, Line 432: neighbor_ident_iter(g_neighbor_cells, nil_match_bts, &d); BTW, when inventing the neighbor_ident, I wanted the API as opaque as possible, which seemed to be a good idea (TM). I have since regretted the choice of an opaque iteration at least five times. Next time I would again go for a transparently open llist instead of a clumsy iter callback mechanism. Considered refactoring it, but probably not worth the effort now... https://gerrit.osmocom.org/#/c/14768/1/src/osmo-bsc/neighbor_ident_vty.c@449 PS1, Line 449: return CMD_WARNING; above comment applies here instead: "it's arguable whether the removal of 0 neighbors is successful or an error (warning esentially is the error, as they only altrenative is CMD_FATAL which terminates the process)." Will return CMD_SUCCESS instead. -- To view, visit https://gerrit.osmocom.org/c/osmo-bsc/+/14768 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bsc Gerrit-Branch: master Gerrit-Change-Id: I8623ab581639e9f8af6a9ff1eca990518d1b1211 Gerrit-Change-Number: 14768 Gerrit-PatchSet: 1 Gerrit-Owner: neels <nhofm...@sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: neels <nhofm...@sysmocom.de> Gerrit-CC: laforge <lafo...@gnumonks.org> Gerrit-Comment-Date: Mon, 29 Jul 2019 17:53:37 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: laforge <lafo...@gnumonks.org> Gerrit-MessageType: comment
