diff options
author | Harald Welte <laforge@gnumonks.org> | 2018-06-02 14:39:08 +0200 |
---|---|---|
committer | Harald Welte <laforge@gnumonks.org> | 2018-06-08 10:22:41 +0000 |
commit | 3385e4b0c491ddd914ce3c7c22c8cb6bef89fc9d (patch) | |
tree | 90cb7d4dd7885290e4647ba8f9a88d744503a5e0 /src/vty/command.c | |
parent | 94e4265f07ead843e455d5085e13c186509a5081 (diff) |
fsm: Change semantics of LOGPFSML() log-level
The general idea about each osmo_fsm_instance having a separate
log-level was to be able to selectively increase/show/enable logging
for some FSM instances (e.g. of a particular subscriber) while
maintaining normal logging verbosity for all other instances of the
same FSM.
The introduction of LOGPFSML() in Change-Id
If295fdabb3f31a0fd9490d1e0df57794c75ae547 broke that idea, as it would
use a compile-time log level, irrespective of the
osmo_fsm_inst.log_level setting of the given instance.
Let's combine the two:
Use the explicit level stated at LOGPFSML(), _unless_ this instance
has a higher log_level configured.
This way, all FSMs should normally be created with
osmo_fsm_inst.log_level == LOGL_DEBUG. At that point LOGPFSM()
statements would be rendered at debug level, typically below the
threshold of most logging configurations.
Code that has explicit higher log levels like LOGPFSML(fi, LOGL_ERROR)
would always be printed, as it is an error message.
And if we now increase the osmo_fsm_inst.log_level, then even the normal
LOGPFSM() statements would suddenly be logged at that higher level,
selectively increasing log verbosity - like originally intended.
Change-Id: I1820f04d0c6f5d5ff08eb95b8c0e88764534491a
Diffstat (limited to 'src/vty/command.c')
0 files changed, 0 insertions, 0 deletions