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 Neels,
On Wed, Jul 25, 2018 at 04:22:09PM +0200, Neels Hofmeyr wrote:
> A) The hardcoded logging landscape on program startup without config.
> (Maybe this isn't all that important, including it nevertheless.)
> 1) a command to reset all to hardcoded defaults?
ACK
> B) A "normal" logging behavior configured by the user. We need:
> 1) a command to set all categories at once
to set all to one level, or to set all to one set of (configurable) defaults,
like a template?
> 2) a command to tweak individual categories
ACK.
> C) Temporarily reducing the logging on all categories: silence the log.
> Even though a category is "normally" set to INFO, after this command it can
> be forced down to only log e.g. NOTICE. But if a category is already on
> ERROR, leave it down there and do not lift it up to NOTICE.
> 1) a command to temporarily reduce all categories.
> 2) a command to temporarily reduce individual categories.
Not sure for what one would use that. You could switch off logging completely
and re-enable it later?
> D) Temporarily increasing the logging on all categories: show everything.
> Even though a category is "normally" set to ERROR, after this command it
> can be forced up to e.g. INFO. But if a category is already up at DEBUG,
> don't reduce it to NOTICE.
> 1) a command to temporarily increase all categories.
> 2) a command to temporarily increase individual categories.
> 3) we need to decide whether temporarily increasing is stronger/weaker than
> temporarily reducing. Depending on the implementation, it could also be
> "last one wins" (which IMHO would be best).
Sounds incredibly complicated to me.
> T) Maybe we also want to unconditionally set temporary levels, whether they
> increase or reduce.
?!?
> E) Remove temporary logging to go back to the "normal" logging landscape.
> 1) a command to put everything back to "normal",
> 2) a command to put individual categories back to "normal",
> 3) a separate command to only remove temporary reduction, i.e lift the
> temporary changes only if they cause less logging than normal,
> 4) a separate command to only remove temporary verbosity, i.e. only lift the
> temporary changes if they cause more logging than normal.
WTF? Why all that complexity?
Honestly, I'm stopping at that point. Just finishing to read that one e-mail,
let alone the entire thread will cost me hours.
To me, it boils down to a hypthetical luxury problem, unless there's
somebody who is actually funding/contributing the amount of time
required to designing, debating, implementing, reviewing and merging and
overhaul of the logging sub-system.
--
- 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)