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/.
Vadim Yanitskiy axilirator at gmail.comHi 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.