Project

General

Profile

Actions

Feature #2356

open

have per-SAPI logging in OsmoBTS DL1P / DL1C

Added by laforge over 6 years ago. Updated almost 4 years ago.

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

80%

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

Actions
Actions #1

Updated by laforge over 6 years ago

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

Updated by laforge over 6 years ago

  • Priority changed from Normal to Low
Actions #3

Updated by laforge about 6 years ago

  • Assignee deleted (msuraev)
Actions #4

Updated by laforge over 5 years ago

  • Assignee set to osmith
Actions #5

Updated by osmith over 4 years ago

  • Status changed from New to In Progress
Actions #6

Updated by osmith over 4 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?

Actions #7

Updated by fixeria over 4 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).

Actions #8

Updated by osmith over 4 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?

Actions #9

Updated by laforge over 4 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.

Actions #10

Updated by osmith over 4 years ago

  • % Done changed from 0 to 90

Thanks, that explanation cleared things up.

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

Actions #11

Updated by osmith over 4 years ago

  • Status changed from In Progress to Feedback
Actions #12

Updated by osmith over 4 years ago

  • Status changed from Feedback to In Progress
Actions #13

Updated by osmith over 4 years ago

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

Patch was merged.

Actions #14

Updated by laforge almost 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 :(

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)