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/.
Pau Espin Pedrol pespin at sysmocom.deHi Vadim, Find my answers in place with your lines. On 24/07/18 19:10, Vadim Yanitskiy wrote: > Hi all, > > A discussion was started during the review of > https://gerrit.osmocom.org/10116/. > The main idea of this change is to fix the behaviour of 'logging level > all LEVEL', > but I think it was also mixed with some additional feature, which I > would like > to discuss here, publicly. > > 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): > > !! Initial logging configuration: > logging level all error > logging level mncc debug > logging level pag notice > logging level meas debug > > !! 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'): > logging level all error > logging level pag notice > logging level meas debug > > This feature looks fine and extremely useful for me. > Everything's correct up to here, and I agree. > 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 As per current code with the mentioned patchset, you should use here "logging level unset debug" to accomplish what you want in this example. Then you get you expected behavior. > > !! 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... > > 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, while 'logging level default LEVEL' > would only affect the default logging level... > Ok so afaiu what you say is that current "unset" becomes "default". Then in "all" we loop over categories and set each with loglevel. > 2) Introducing the new command: > > # logging level unset LEVEL > > which is intended to assign a given LEVEL to all categories, > which have no custom logging level (i.e. have 'unset'), would > make the idea of having default logging policy meaningless. Currently (with patchset), "unset" actually sets the target loglevel, aka the default, so it doesn't make default meaningless because it uses it. The difference with current "all" is that it doesn't reset the categories to unset. > > Setting logging level(s) for all possible categories (using this > command), looks like writing iptables rules for all possible > and impossible cases instead of using the DEFAULT policy... I don't get your point here. You can do both. > > 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. > > As we (me and Pau) have different opinions, or we simply don't > understand each other, let's make this discussion public, and > let's see what others think about this... > > With best regards, > Vadim Yanitskiy. So, after your comments and thinking about it, here's my proposal: 1- Take my current patchset 2- Modification: "logging level all <loglevel>" sets the loglevel foreach category, not the target loglevel (aka the default loglevel). 3- Modification: "logging level unset <loglevel>" is renamed to "logging level default <loglevel>" 4- Addition: New VTY cmd "logging level unset-all" is introduced, which sets all categories to UNSET (basically re-use the current loop we have in current patchset handling the "all"). For num.4, we could actually use "logging level all unset", which makes perfectly sense and matches with expectations. Agree? -- - Pau Espin Pedrol <pespin at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte