<p><a href="https://gerrit.osmocom.org/12211">View Change</a></p><p>1 comment:</p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0;"><p><a href="https://gerrit.osmocom.org/#/c/12211/1//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/12211/1//COMMIT_MSG@11">Patch Set #1, Line 11:</a> <code style="font-family:monospace,monospace">the passed level and the FSM instance's level. Too noisy!</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">Why do we do the max() instead of simply using the log level passed by the macro? that looks really  […]</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">that comes from the initial idea of osmo_fsm logging:</p><p style="white-space: pre-wrap; word-wrap: break-word;">At first there was no LOGPFSML -- an FSM instance would have its single log level, and all of it would log on that level. The idea was that e.g. via CTRL interface, single FSM instances (for a specific subscriber...)  could be tweaked. I think the idea was that it only logs osmo_fsm internal things like state transitions.</p><p style="white-space: pre-wrap; word-wrap: break-word;">But the log context of the FSM turned out super useful: no need to manually add logging context in each LOGP() anymore, just LOGPFSM("plain string"). So then I needed to add LOGPFSML(), because even though some FSM instance might be on DEBUG, I still need to be able to e.g. LOGL_ERROR, while still using that FSM instance's logging context printout.</p><p style="white-space: pre-wrap; word-wrap: break-word;">So now the situation is that basically all FSM instances should start out on DEBUG, but individual LOGPFSML() might pass higher-prio logging levels. However, if a user lifts a specific FSM instance's log level up to say NOTICE, she wants all log messages to rise, even for LOGPFSML(LOGL_DEBUG) messages.</p><p style="white-space: pre-wrap; word-wrap: break-word;">Lifting individual FSM instances' log levels has so far not come in handy for me, it might turn out to be a non-feature. But it might become useful in combination with log filters: in systems with thousands of subscribers, we have this bitrotten feature of showing only a specific subscriber's logging, using logging filter commands. If we at some point want to fix that, it might help by automatically lifting given subscribers' FSM instances' log levels... i've been pondering that every now and then, but not figured out a proper solution yet</p></li></ul></li></ul><p>To view, visit <a href="https://gerrit.osmocom.org/12211">change 12211</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/12211"/><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: Ie021483e93ab174abac51357bcca8895756566c4 </div>
<div style="display:none"> Gerrit-Change-Number: 12211 </div>
<div style="display:none"> Gerrit-PatchSet: 1 </div>
<div style="display:none"> Gerrit-Owner: Neels Hofmeyr <nhofmeyr@sysmocom.de> </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-CC: Pau Espin Pedrol <pespin@sysmocom.de> </div>
<div style="display:none"> Gerrit-Comment-Date: Mon, 10 Dec 2018 13:37:30 +0000 </div>
<div style="display:none"> Gerrit-HasComments: Yes </div>
<div style="display:none"> Gerrit-HasLabels: No </div>