Project

General

Profile

Feature #2356

have per-SAPI logging in OsmoBTS DL1P / DL1C

Added by laforge over 2 years ago. Updated 14 days ago.

Status:
Resolved
Priority:
Low
Assignee:
Category:
-
Target version:
-
Start date:
07/10/2017
Due date:
% Done:

100%

Spec Reference:

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

Related to OsmoBTS - Bug #2355: optimize log output of phy specific codeNew07/10/2017

History

#1 Updated by laforge over 2 years ago

  • Related to Bug #2355: optimize log output of phy specific code added

#2 Updated by laforge about 2 years ago

  • Priority changed from Normal to Low

#3 Updated by laforge almost 2 years ago

  • Assignee deleted (msuraev)

#4 Updated by laforge about 1 year ago

  • Assignee set to osmith

#5 Updated by osmith 3 months ago

  • Status changed from New to In Progress

#6 Updated by osmith 3 months 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?

#7 Updated by fixeria 3 months 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).

#8 Updated by osmith 3 months 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?

#9 Updated by laforge 3 months 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.

#10 Updated by osmith 3 months ago

  • % Done changed from 0 to 90

Thanks, that explanation cleared things up.

Patches submitted: https://gerrit.osmocom.org/q/topic:sapi-filter

#11 Updated by osmith 3 months ago

  • Status changed from In Progress to Feedback

#12 Updated by osmith 3 months ago

  • Status changed from Feedback to In Progress

#13 Updated by osmith 14 days ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100

Patch was merged.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)