<p><a href="https://gerrit.osmocom.org/c/osmo-bsc/+/14768">View Change</a></p><p>5 comments:</p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0;"><p><a href="https://gerrit.osmocom.org/#/c/14768/1/src/osmo-bsc/neighbor_ident_vty.c">File src/osmo-bsc/neighbor_ident_vty.c:</a></p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.osmocom.org/#/c/14768/1/src/osmo-bsc/neighbor_ident_vty.c@392">Patch Set #1, Line 392:</a> <code style="font-family:monospace,monospace">static int del_all(struct vty *vty)</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">let's make this a bit more descriptive like neighbor_del_all, neigh_del_all, bts_remove_all_neighbor […]</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">I figured since it's in the static context, the short name would do.<br>But indeed, in other places I argued for longer names. so ack.</p></li><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.osmocom.org/#/c/14768/1/src/osmo-bsc/neighbor_ident_vty.c@403">Patch Set #1, Line 403:</a> </p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><pre style="font-family: monospace,monospace; white-space: pre-wrap;">if (!bts) {<br> vty_out(vty, "%% Error: cannot remove BTS neighbor, no BTS on this node%s",<br> VTY_NEWLINE);<br> return CMD_WARNING;<br> }<br></pre></blockquote></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">it's arguable whether the removal of 0 neighbors is successful or an error (warning esentially is th […]</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">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.</p></li><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.osmocom.org/#/c/14768/1/src/osmo-bsc/neighbor_ident_vty.c@410">Patch Set #1, Line 410:</a> </p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><pre style="font-family: monospace,monospace; white-space: pre-wrap;">while (1) {<br> struct gsm_bts_ref *neigh = llist_first_entry_or_null(&bts->local_neighbors, struct gsm_bts_ref, entry);<br></pre></blockquote></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">why are we not using llist_for_each_entry() here? It seems more natural to me. […]</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">This is a style bikeshed...</p><p style="white-space: pre-wrap; word-wrap: break-word;">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.</p></li><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.osmocom.org/#/c/14768/1/src/osmo-bsc/neighbor_ident_vty.c@432">Patch Set #1, Line 432:</a> <code style="font-family:monospace,monospace"> neighbor_ident_iter(g_neighbor_cells, nil_match_bts, &d);</code></p><p style="white-space: pre-wrap; word-wrap: break-word;">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...</p></li><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.osmocom.org/#/c/14768/1/src/osmo-bsc/neighbor_ident_vty.c@449">Patch Set #1, Line 449:</a> <code style="font-family:monospace,monospace"> return CMD_WARNING;</code></p><p style="white-space: pre-wrap; word-wrap: break-word;">above comment applies here instead:<br>"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)."</p><p style="white-space: pre-wrap; word-wrap: break-word;">Will return CMD_SUCCESS instead.</p></li></ul></li></ul><p>To view, visit <a href="https://gerrit.osmocom.org/c/osmo-bsc/+/14768">change 14768</a>. To unsubscribe, or for help writing mail filters, visit <a href="https://gerrit.osmocom.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.osmocom.org/c/osmo-bsc/+/14768"/><meta itemprop="name" content="View Change"/></div></div>
<div style="display:none"> Gerrit-Project: osmo-bsc </div>
<div style="display:none"> Gerrit-Branch: master </div>
<div style="display:none"> Gerrit-Change-Id: I8623ab581639e9f8af6a9ff1eca990518d1b1211 </div>
<div style="display:none"> Gerrit-Change-Number: 14768 </div>
<div style="display:none"> Gerrit-PatchSet: 1 </div>
<div style="display:none"> Gerrit-Owner: neels <nhofmeyr@sysmocom.de> </div>
<div style="display:none"> Gerrit-Reviewer: Jenkins Builder </div>
<div style="display:none"> Gerrit-Reviewer: neels <nhofmeyr@sysmocom.de> </div>
<div style="display:none"> Gerrit-CC: laforge <laforge@gnumonks.org> </div>
<div style="display:none"> Gerrit-Comment-Date: Mon, 29 Jul 2019 17:53:37 +0000 </div>
<div style="display:none"> Gerrit-HasComments: Yes </div>
<div style="display:none"> Gerrit-Has-Labels: No </div>
<div style="display:none"> Comment-In-Reply-To: laforge <laforge@gnumonks.org> </div>
<div style="display:none"> Gerrit-MessageType: comment </div>