<blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">I ran "git grep SAPI" in osmo-bts.git, and got the most matches<br>inside the common dir in pcu_sock.c. But I know now, that I should<br>have researched it better.</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">if you used case insensitive matches you would have found that most matches are outside common.</p><pre style="font-family: monospace,monospace; white-space: pre-wrap;"><br> > What I'm still struggling with is, how one should extract the L1<br> > SAPI value from every L1P/L1C primitive. With "as soon as possible"<br> > you could either mean in the code of the various PHYs or in<br> > common/l1sap.c's l1sap_up() function (because that is the first<br> > time, the primitive is passed to the common code).</pre><p style="white-space: pre-wrap; word-wrap: break-word;">you must do it in the bts-specific part - not in the PHY, as the PHY is outside of osmo-bts.</p><p style="white-space: pre-wrap; word-wrap: break-word;">The rationale for that is quite obvious: It is exactly the tons of log statements (primarily LOGL_DEBUG)<br>in the BTS-specific code that require the filtering.  In order for any filtering to be effective,<br>it must be set as soon as possible, before any of those log statements are hit.</p><p style="white-space: pre-wrap; word-wrap: break-word;">So to look at osmo-bts-sysmo as an example: l1if_handle_ind() or probably more likely in<br>handle_ph_data_ind(), handle_ph_ra_ind() and handle_ph_readytosend_ind() one would set that filter.</p><p style="white-space: pre-wrap; word-wrap: break-word;">In handle_ph_data_ind, the phy/bts-specific SAPI value can be found in data_ind->sapi.  You add<br>one function to translate it to some new (common/shared) SAPI enum (if no such enum exists yet)<br>and set the log filter.</p><p style="white-space: pre-wrap; word-wrap: break-word;">the main point is that the log context must be set *before* any related log messages are generated,<br>and that is in the downlink transmit direction in the common part, (RSL->LAPDm->common->specific->PHY) and in the uplink receive direction it's the BTS-specific part as the order is inverse.</p><p><a href="https://gerrit.osmocom.org/c/osmo-bts/+/15539">View Change</a></p><ul style="list-style: none; padding: 0;"></ul><p>To view, visit <a href="https://gerrit.osmocom.org/c/osmo-bts/+/15539">change 15539</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-bts/+/15539"/><meta itemprop="name" content="View Change"/></div></div>

<div style="display:none"> Gerrit-Project: osmo-bts </div>
<div style="display:none"> Gerrit-Branch: master </div>
<div style="display:none"> Gerrit-Change-Id: I6b7bb2e1d61502b61214f854a4ec5cbb7267545b </div>
<div style="display:none"> Gerrit-Change-Number: 15539 </div>
<div style="display:none"> Gerrit-PatchSet: 4 </div>
<div style="display:none"> Gerrit-Owner: osmith <osmith@sysmocom.de> </div>
<div style="display:none"> Gerrit-Reviewer: Jenkins Builder </div>
<div style="display:none"> Gerrit-Reviewer: fixeria <axilirator@gmail.com> </div>
<div style="display:none"> Gerrit-Reviewer: laforge <laforge@gnumonks.org> </div>
<div style="display:none"> Gerrit-Reviewer: neels <nhofmeyr@sysmocom.de> </div>
<div style="display:none"> Gerrit-Reviewer: osmith <osmith@sysmocom.de> </div>
<div style="display:none"> Gerrit-Reviewer: pespin <pespin@sysmocom.de> </div>
<div style="display:none"> Gerrit-CC: fixeria <axilirator@gmail.com> </div>
<div style="display:none"> Gerrit-Comment-Date: Tue, 24 Sep 2019 16:36:00 +0000 </div>
<div style="display:none"> Gerrit-HasComments: No </div>
<div style="display:none"> Gerrit-Has-Labels: No </div>
<div style="display:none"> Gerrit-MessageType: comment </div>