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

neels gerrit-no-reply at
Mon Jul 29 17:53:37 UTC 2019

neels has posted comments on this change. ( )

Change subject: add vty 'no neighbors' to remove all HO targets

Patch Set 1:

File src/osmo-bsc/neighbor_ident_vty.c: 
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. 
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. 
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. 
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... 
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
To unsubscribe, or for help writing mail filters, visit

Gerrit-Project: osmo-bsc
Gerrit-Branch: master
Gerrit-Change-Id: I8623ab581639e9f8af6a9ff1eca990518d1b1211
Gerrit-Change-Number: 14768
Gerrit-PatchSet: 1
Gerrit-Owner: neels <nhofmeyr at>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: neels <nhofmeyr at>
Gerrit-CC: laforge <laforge at>
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>
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the gerrit-log mailing list