<p style="white-space: pre-wrap; word-wrap: break-word;">please bear with my scepticism, as the way the FSMs interact can become quite complex and I want to understand the implications before I approve.</p><p>Patch set 2:<span style="border-radius: 3px; display: inline-block; margin: 0 2px; padding: 4px;background-color: #ffd4d4;">Code-Review -1</span></p><p><a href="https://gerrit.osmocom.org/11995">View Change</a></p><p>2 comments:</p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0;"><p><a href="https://gerrit.osmocom.org/#/c/11995/2//COMMIT_MSG">Commit Message:</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/11995/2//COMMIT_MSG@10">Patch Set #2, Line 10:</a> <code style="font-family:monospace,monospace">to handle them, as a result from dispatching LCHAN_EV_TS_ERROR previously.</code></p><p style="white-space: pre-wrap; word-wrap: break-word;">I don't understand: which state is unable to handle TS_EV_LCHAN_UNUSED? If it should be able to, then let's make it handle that event properly?</p></li></ul></li><li style="margin: 0; padding: 0;"><p><a href="https://gerrit.osmocom.org/#/c/11995/2/src/osmo-bsc/timeslot_fsm.c">File src/osmo-bsc/timeslot_fsm.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/11995/2/src/osmo-bsc/timeslot_fsm.c@177">Patch Set #2, Line 177:</a> <code style="font-family:monospace,monospace">       ts_lchans_dispatch(ts, LCHAN_ST_WAIT_TS_READY, LCHAN_EV_TS_ERROR);</code></p><p style="white-space: pre-wrap; word-wrap: break-word;">Sorry, I'm not convinced:</p><ul><li>my premise is that the lchan should be able to handle a TS_ERROR independently from the timeslot's state.</li></ul><ul><li>when a timeslot changes its state, it might trigger immediate other actions, maybe also affecting lchans. I'm imagining an lchan being put up for more activity before it was even told that there was some problem before...</li></ul><p style="white-space: pre-wrap; word-wrap: break-word;">I'm sure you've seen an example that shows that this makes sense; instead I'm arguing from the angle of the ideas and premises I had in mind when writing the way the FSMs interact, trying to cover all (un)thinkable situations.</p></li></ul></li></ul><p>To view, visit <a href="https://gerrit.osmocom.org/11995">change 11995</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/11995"/><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-MessageType: comment </div>
<div style="display:none"> Gerrit-Change-Id: If61493e7d5449bf2c2de9fd34cdf2410625e92ac </div>
<div style="display:none"> Gerrit-Change-Number: 11995 </div>
<div style="display:none"> Gerrit-PatchSet: 2 </div>
<div style="display:none"> Gerrit-Owner: Pau Espin Pedrol <pespin@sysmocom.de> </div>
<div style="display:none"> Gerrit-Reviewer: Harald Welte <laforge@gnumonks.org> </div>
<div style="display:none"> Gerrit-Reviewer: Jenkins Builder (1000002) </div>
<div style="display:none"> Gerrit-Reviewer: Neels Hofmeyr <nhofmeyr@sysmocom.de> </div>
<div style="display:none"> Gerrit-Comment-Date: Thu, 29 Nov 2018 18:27:58 +0000 </div>
<div style="display:none"> Gerrit-HasComments: Yes </div>
<div style="display:none"> Gerrit-HasLabels: Yes </div>