This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi Vadim,
as I'm back from holidays, I'm catching up with mails, including this thread here.
On Wed, Jul 25, 2018 at 12:10:08AM +0700, Vadim Yanitskiy wrote:
> First of all, the change introduces a new special logging level 'unset',
> which allows one to reset a given category (i.e. unset its custom value):
>
> [..]
> !! Resetting DMNCC:
> # logging level mncc unset
>
> !! So, now DMNCC has no custom log level, it will use
> !! the default level (in this example it is 'error'):
but what is the "default level"? I assume as you're talking about interactive
changes, you are talking about logging to a VTY. What is the default that you
fall-back to? Unlike file/syslog targets, the VTY doesn't have any configurable
defaults
> But (among fixing) this change additionally changes the behaviour
> of a command for setting the default logging category (i.e. 'logging
> level all LEVEL'):
>
> !! Initial logging configuration:
> logging level all error
> logging level mncc debug
> logging level pag notice
> logging level meas debug
>
> !! Changing the default logging level:
> # logging level all debug
>
> !! Ahhh, I've lost my custom levels :(
> logging level all debug
>
> !! What I expected to get:
> logging level all debug
> logging level mncc debug
> logging level pag notice
> logging level meas debug
>
> So, together with changing the default logging category,
> this command now would also reset all custom settings...
To be honest, I don't think I have any idea at all what "logging level all" does,
I have never used it. I find it quite confusing that there are other things than
setting the per-subsystem levels. Setting per-subsystem categories makes sense to me,
everything else seems strange...
> I am not sure this is exactly what one need/expect, so
> I would like to share the following ideas:
>
> 1) The category 'all' looks/sounds confusing when it's used
> in such cases like this:
>
> # logging level all debug
>
> because one can interpret it like:
>
> "set all categories to debug".
>
> despite actually (according to the implementation) this
> is related to the default logging policy.
>
> Maybe, we should rename it to 'default'?
> So, 'logging level all LEVEL' would *set all categories*
> to a given logging LEVEL,
I agree this is more intuitive from the meaning of the word "all",
but I think that would be only ever used to set a global "sane" logging
level like NOTICE or ERROR. You certainly don't want to set DEBUG on
all categories, as otherwise you're going to be spammed and will drown
in too much information.
> while 'logging level default LEVEL'
> would only affect the default logging level...
What is the "default logging level" ? The level compiled-into the struct
log_info?
> 3) The introduced behaviour of resetting all categories to 'unset'
> could be implemented in a separate function, and can be
> represented by a separate command:
>
> # logging level unset-all
>
> The name of this command clearly defines the expected behaviour.
> Moreover, it doesn't affect the default logging level, which can be
> still changed by a separate command.
How would you ever change the default? I thought that's the compiled-in part?
Resetting the current logging masks to those default compiled-in ones by a single
command seems like a useful feature to me. My practical work-around for this is to simply
close + re-open the VTY session...
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)