logging level all everything

Neels Hofmeyr nhofmeyr at sysmocom.de
Tue Sep 11 12:54:36 UTC 2018

On Tue, Sep 11, 2018 at 10:57:16AM +0200, Pau Espin Pedrol wrote:
> As I already shared in last discussion about this topic, I agree with
> keeping and fixing "logging level all" instead of dropping it and creating a
> new command, because imho most if not all users of "logging level all" in
> config files expect the fixed behavior (set each category to level X).

But "logging level all" does *not* set each category to level X, instead it
sets a global forced level over and above the individually set log levels,
which stays clamped on forever regardles of individual logging levels set.

I almost had re-used it to mean "set each", basically accepting your patch as
it is, but after all I do agree with laforge that it is better to not re-use
the same name to mean something different.

> Dropping and adding a new command is going to add far more breakage than
> fixing it.

Not dropping, just deprecating. They will remain available, but not be
prominently visible in vty online doc / command autocompletion.

So ... after all of your input ...

<Dignified Ceremonial Silence>

In Accordance with my Title of
  Supreme Grand Master of Logging and Reforestation
I Decree that we Shall:

- keep 'logging level all', and bring back 'everything', properly documented,
  but marked as deprecated. That means the old clamping behavior is still there
  (the code itself is trivial), but the commands do not appear when querying
  the VTY cmdline doc. Why keep it? So that old config files still work as they
  did when conceived.  Why hide it? because the naming is misleading to most of
  us, and it's less trouble to just see the new ones with a clear meaning.

- add 'logging level set-all' to set each category once-off.

- add 'logging level force-all <LVL>' and 'no logging level force-all' as
  aliases for 'all <LVL>' and 'all everything' to not write deprecated commands
  to file.

I agree that we want to stop discussing this now. This is both an example of
Bikeshedding and of why writing new software can be faster than changing old

(If you disagree with the above, I don't want to shut you up, everyone is
always allowed to talk more, regardless. Just offering to relieve everyone of
the burden now.)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180911/726f0b36/attachment-0001.bin>

More information about the OpenBSC mailing list