The magic behaviour of 'logging level all LEVEL'

[Neels Hofmeyr]

Before this echoing of the same arguments over and over continues between you
and me, Pau, let's stop this here and let me do my homework in the logging
code. I'll try to clarify what I mean, but I see I need to prove my points.

> Ok so let's leave it broken and useless then? Deprecate it and write an
> entire new system? No, thanks.

Introducing new commands that work properly is IMO the only viable solution to
fix old broken UI. IIUC your patch adds new commands?

So I'd like to clarify how the implementation affects what old commands did,
and whether it permits implementing per-category defaults without problems.

> What do you mean with fine-grained default levels?

Still not clear, is it? I want to set various categories to various log levels
to taste, then go to say DEBUG on some/all of them, then later go back to
exactly the levels selected before.

It's like your default log level, just not one across all categories, but one
level per category.

Your suggestion:

                           level
                             ^
                             |     -
  Normal logging landscape== | =====================
          Temporary levels-- | --               -
                             |      --   ----  -
                             |________________________> categories


What I'd like to support:

                           level
                             ^
                             |     - ======    =
  Normal logging landscape== | ==  ==      ==     --
          Temporary levels-- | -- =          == -  =
                             |   =  --   ----  -===
                             |________________________> categories


This includes the possibility of having all of them at the same level, so it
seems we are just very verbosely arguing about the implementation and UI
details.

> Having a way to go back to hardcoded initial values?

Please let go of the hardcoded defaults, they aren't important, I did say so a
number of times now.

> If you still want more temporary levels (increase/decrease or whatever you
> call it)

Do I read a dismissive tone here? :P

> per logtarget

Everything is always inherently per logtarget!

> or even per category,

exactly

> you can add them later and
> check them before the other levels in should_log_to_target(), then change
> them with new VTY commands.

If you introduce one common default level for all categories, I fear that it
conflicts with the use case to have separate defaults for each category. I
still need to prove that.

> It's compatible with old UI. All programs using the API continue to work
> fine as well as old cfg files. It adds new parameter "logging level default
> <loglevel>" and "logging level <category> unset", that's all. So it fixes
> broken logging level all and adds extra feature to make it useful.

Don't the code changes modify how 'logging level all foo' behaves?
I have to do my homework to strengthen my argument here.

> > > 1- Open a new VTY, then call logging level all debug
> > 
> > true. Any opinions on this one, Keith maybe?

If monitoring e.g. BTS or PCU on a slow ARM, opening multiple log targets
might impact stability.

> You can even just re-open the session you have opened, no need to open a
> second one.

But then you lose the specific logging selection that you want to keep.

~N
-------------- 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/20180726/aec5d858/attachment.bin>