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.deOn 25/07/18 18:12, Neels Hofmeyr wrote: > On Wed, Jul 25, 2018 at 05:31:59PM +0200, Pau Espin Pedrol wrote: >> A) It's already there as it is now, no need to change. When you start a >> program, code harcoded categories are set with a given loglevel. > > But currently no way to get back to it, IIUC. Not important anyway. No, we cannot, we would probably require a new API to store them as "harcoded categories", and some VTY command to set them. If somebody thinks it's needed and really useful, patches welcome. I think it's not that useful and I want to keep the logging system as simple as possible while still providing useful ways to fine-grain loglvels. > >> C) D) T) E) >> I fins all this "temporary" stuff something really not there in current >> code, too complex and not really required. > > We actually supported temporary logging increase, even though I never grokked > how it was supposed to work, hence I broke it by removing the logging level all > everything. > > This is an attempt to bring it back in an obvious and finely tunable way. It is > not really complex, is it!? Same as my last above comment. My intention with this patchset was to have the logging working again trying not to touch that much, and avoid spending much time on it. If at some point we supported the feature, it's not the case anymore nowadays. If somebody wants to re-add that feature and change the logging system, patches welcome. > >> Current proposed system is basically (and very similar to old system, just a >> bit better sort out imho): > > A problem there is that it is changing the meaning of a logging command that > has been there for a decade. Because I fail to understand why exactly it isn't > doing what I want and why it was implemented this way, and because I accept > that other users might rely on exactly the current behavior to do what they > want, I would prefer keeping it unchanged and to add new command names that > make proper sense to us (to not repeat my past mistake). I think current behavior (for logging level all) is imho totally broken and the patchset I'm proposing changes behavior of old commands only minimally. > - I have setup a detailed logging landscape, i.e. not one default level for all > categories, but a fine grained selection: some on error, some on notice, some > on info, > - Now for a minute I want to quickly see all debug logging. > logging increase debug all > - Later I want to go back to the detailed landscape. > logging reset all Someone can always add these feature on top of present patchset if there's enough use for it. This feature is not there now, so I'm not removing it with presented patchset. I personally think the scenario you presented can be workarounded pretty easily in different ways, so I personally think there's no urgent need for it: 1- Open a new VTY, then call logging level all debug 2- Write down the commands you used to set the logging, then paste them after running "logging level default debug; logging level all unset" to see all logging for a while. -- - 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