The magic behaviour of 'logging level all LEVEL'

[Vadim Yanitskiy]

Hi Harald,

> as I'm back from holidays, I'm catching up with mails,
> including this thread here.

Nice to see you are back :)

I didn't expect this thread would grow so much. Probably,
because we started to discuss the new features...
But let's focus on the initial thread topic.

> but what is the "default level"?
> What is the default that you fall-back to?

I mean the global log level of a logging target, please see:

https://git.osmocom.org/libosmocore/tree/include/osmocom/core/logging.h#n243

At the moment, it can be set with 'logging level all LEVEL',
but anyway it doesn't work as expected, please see:

https://osmocom.org/issues/3409

and this change by Pau which still mixes new features with
actual bugfixing (src/logging.c#479):

https://gerrit.osmocom.org/10116/

For some reason, I do associate libosmocore's logging subsystem
with iptables. Please don't think I am crazy, there are really
some similarities:

  - Instead of filtering packets, we are filtering
    the logging messages;

  - Logging target (e.g. stderr, or a file) is like a chain;

  - The global log level of a logging target (I usually
    refer this as 'the default logging level') is like
    the default policy of a chain;

  - If a logging category (e.g. 'meas' or 'l1c') has a custom
    logging level (e.g. 'debug'), one may interpret this as a
    rule in a chain. If there is no rule for a given category
    the default logging level can be used (like default policy).

> To be honest, I don't think I have any idea at all
> what "logging level all" does,

Meanwhile, we do have this line in some sample configuration
files, and if there is no this line, we always have the
following result of calling 'show running-config' or 'write file':

  logging level all everything

This is why we (at least me and Pau) would like to introduce
an idea of a bit more self-explaining command:

  logging level default debug

> Setting per-subsystem categories makes sense to me,
> everything else seems strange...

Well, I think it makes sense to have some global / default
logging level (e.g. 'error'), and a set of per-subsystem
levels. For example, I would like to debug some particular
subsystem / category (e.g. DMNCC), and silence all other:

  logging level default error
  logging level mncc debug

Another important feature (I think) is a possibility to
unset either a particular subsystem / category, or all
subsystems / categories, which would fall-back to value
of the default logging level for the current target.

For example, I am running a program with the following
logging configuration:

  logging level default notice
  logging level mncc debug
  logging level pag error
  logging level l1c debug
  logging level l1d info
  ...

and now I would like to debug DPAG at run-time, so I could
unset all custom values from VTY, and set DPAG to 'debug':

  (VTY)# logging level default error
  (VTY)# logging level all unset
  (VTY)# logging level pag debug

Result:

  logging level default error
  logging level pag debug

Finally, let's conclude my ideas in short all in one place:

  - Introduce 'unset' keyword;

  - Introduce self-explaining 'logging level default ...'
    which is aimed to set the (default / global) log
    level of a given logging target (e.g. 'stderr');

  - Modify the behaviour of 'logging level all ...' to
    affect all logging categories (e.g. 'logging level
    all unset' would unset all custom user-defined levels,
    'logging level all error' would sett all to 'error').

P.S. Sorry for 'the default', I hope this explaination is better.

With best regards,
Vadim Yanitskiy.