Feature #2356
openhave per-SAPI logging in OsmoBTS DL1P / DL1C
80%
Description
the L1 logging is inherently verbose, particularly for L1P.
It would be nice if one could enable logging only for specific L1 SAPIs, such as SACCH, TCH, FACCH, or the like.
Having different log subsystems is overkill, but maybe the 'log filter' framework can be used for this?
Related issues
Updated by laforge almost 7 years ago
- Related to Bug #2355: optimize log output of phy specific code added
Updated by osmith almost 5 years ago
Having different log subsystems is overkill, but maybe the 'log filter' framework can be used for this?
If I understood it right, this is how we would make use of the 'log filter' framework. Set the SAPI log context before each log message and reset it afterwards (either like this or with a macro):
LOGP(DL1P, LOGL_ERROR, "L1 HR frame length %u != expected %u\n", payload_len, GSM_HR_BYTES);
log_set_context(LOG_CTX_SAPI, TCH); LOGP(DL1P, LOGL_ERROR, "L1 HR frame length %u != expected %u\n", payload_len, GSM_HR_BYTES); log_set_context(LOG_CTX_SAPI, NULL);
laforge: I'm wondering why this is better than simply using a separate log subsystem, can you elaborate?
Updated by fixeria almost 5 years ago
log_set_context(LOG_CTX_SAPI, NULL);
If I remember correctly, you don't need to reset the context yourself as it's done by osmo_select_main().
The general approach is that you set the context at the beginning of a function and forget about it (excluding some special cases).
Updated by osmith almost 5 years ago
fixeria wrote:
log_set_context(LOG_CTX_SAPI, NULL);
If I remember correctly, you don't need to reset the context yourself as it's done by osmo_select_main().
The general approach is that you set the context at the beginning of a function and forget about it (excluding some special cases).
Thanks! I found this related issue #3813.
But still, it seems like one would re-implement the log subsystems as filter if it was done as proposed above... could somebody explain to me why this is better than directly using a different subsystem?
Updated by laforge almost 5 years ago
On Wed, Sep 11, 2019 at 08:48:19AM +0000, osmith [REDMINE] wrote:
Issue #2356 has been updated by osmith.
Having different log subsystems is overkill, but maybe the 'log filter' framework can be used for this?
If I understood it right, this is how we would make use of the 'log filter' framework. Set the SAPI log context before each log message and reset it afterwards (either like this or with a macro):
no, that would be crazy. The idea is that once you know which SAPI is currently processed,
the log context is set. Any subsequent log statements then mus relate to this SAPI. The context
should be reset just before going back into the select loop, orjust after returning from it,
and the reset might (should) actually happen in libosmocore itself.
The point is that whenever we come out of the select loop code, we are processing one
particular message, and that message relates to one specific (SAPI, BTS, TRX, IMSI, ...)
and as soon as we have identified those bits, we can set the related log context for
the entire duration until we go back into the select loop.
Updated by osmith almost 5 years ago
- % Done changed from 0 to 90
Thanks, that explanation cleared things up.
Patches submitted: https://gerrit.osmocom.org/q/topic:sapi-filter
Updated by osmith almost 5 years ago
- Status changed from In Progress to Feedback
Waiting for feedback on that comment: https://gerrit.osmocom.org/c/osmo-bts/+/15539#message-c5abaebc604578ba5ade4d9ac63d407d09eacbc4
Updated by osmith almost 5 years ago
- Status changed from Feedback to In Progress
Updated by osmith over 4 years ago
- Status changed from In Progress to Resolved
- % Done changed from 90 to 100
Patch was merged.
Updated by laforge over 4 years ago
- Status changed from Resolved to New
- % Done changed from 100 to 80
unfortunately the implementation has skipped support for osmo-bts-trx and osmo-bts-virtual :(