On 11/09/18 05:41, Harald Welte wrote:
Hi Neels,
On Mon, Sep 10, 2018 at 11:26:46PM +0200, Neels Hofmeyr wrote:
> So, I want to make 'logging level all' manipulate each individual category
> once-off, I want to completely deprecate the 'everything' keyword, and drop
the
> "global clamp" feature entirely.
>
> Maybe I'd re-add the clamp as 'logging level force-all (debug|...|fatal)'
and
> 'no logging level force-all' to switch it off. That would be exactly the old
> clamping feature just with less confusing names.
Well, I was in favour of the
"clamp" originally, and I was using it a
lot, hence my manual patching for a while of libosmocore to restore
"everything" as "clamp-remover".
I use it less now, if ever I do do something like logging level all
debug, I know I have to exit the vty and start again to remove the clamp.
The only thing that makes me write here is that I'm only 90% sure on changing
the meaning of an existing command, of 'logging level all'. If there is no
negative feedback on this here, that would bring me to 100%.
In terms of
semantics, old notes/documentation, etc. I would suggest to simply
deprecate "all" and introduce a new command instead. If the global clamping
is removed, then "logging level all debug" could simply become a no-op, so if
people
type it in because they are used to it, or have it in some old configs, no
harm is done. And if they use "logging level all notice" then they should get
a non-fatal warning/notice message that this command is no longer supported.
You /could/ just reinstate the "all everything" as clamp remover.
Note that doing "write" in the vty still writes a "logging level all
everything" line to the config, causing a warning on startup:
% Ignoring deprecated logging level everything
Then leave logging level all notice meaning "clamp to notice" (as it
always was).
I honestly never found this difficult to understand once I understood
how it worked, so I'd suggest documenting "all" as a "clamp" and
suggesting prefer the use of "set-all"
So in short: I suggest to not overload existing keywords, but introducing new ones
with well-defined/documented meaning.
Then add logging level set-all [level]?
set-all makes most sense to me out of the suggestions, for a temporary
But again... I really don't mind.. I don't want to wreck your head,
Neels, in making decisions. Deprecate 'all' if you want.
As I said before I just use expect scripts as shell functions to setup
different logging scenarios:
rhizomatica@rccnII:~$ type nitb_cc
nitb_cc is a function
nitb_cc ()
{
/usr/bin/expect -c 'spawn telnet localhost 4242;send "enable\r";send
"logging enable\r";send "logging print category 1\r";send
"logging level
smpp fatal\r"; send "logging level mncc debug\r"; send "logging level
cc
debug\r"; send "logging filter all 1\r"; interact'
}
I think this is easier that trying to put that functionality into
osmocore itself.. which would be something like
logging level foo bar.. [..repeat according to preferences..]
then
logging scenario save mylogging
logging scenario load mylogging
One has more urgent things to do.. right?
k/