Change in ...osmo-bsc[master]: add vty 'no neighbors' to remove all HO targets

[neels]

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 <nhofmeyr at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: neels <nhofmeyr at sysmocom.de>
Gerrit-CC: laforge <laforge at 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 <laforge at gnumonks.org>
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20190729/605580e6/attachment.htm>