This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.
Neels Hofmeyr gerrit-no-reply at lists.osmocom.orgNeels Hofmeyr has posted comments on this change. ( https://gerrit.osmocom.org/12211 )
Change subject: set gscon FSM instances' log level to DEBUG
......................................................................
Patch Set 1:
(1 comment)
https://gerrit.osmocom.org/#/c/12211/1//COMMIT_MSG
Commit Message:
https://gerrit.osmocom.org/#/c/12211/1//COMMIT_MSG@11
PS1, Line 11: the passed level and the FSM instance's level. Too noisy!
> Why do we do the max() instead of simply using the log level passed by the macro? that looks really […]
that comes from the initial idea of osmo_fsm logging:
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.
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.
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.
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
--
To view, visit https://gerrit.osmocom.org/12211
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-bsc
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: Ie021483e93ab174abac51357bcca8895756566c4
Gerrit-Change-Number: 12211
Gerrit-PatchSet: 1
Gerrit-Owner: Neels Hofmeyr <nhofmeyr at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder (1000002)
Gerrit-Reviewer: Neels Hofmeyr <nhofmeyr at sysmocom.de>
Gerrit-CC: Pau Espin Pedrol <pespin at sysmocom.de>
Gerrit-Comment-Date: Mon, 10 Dec 2018 13:37:30 +0000
Gerrit-HasComments: Yes
Gerrit-HasLabels: No
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20181210/9a2a03d7/attachment.htm>