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/.
Neels Hofmeyr nhofmeyr at sysmocom.deHi all, for logging changes, I would welcome a comprehensive approach and maybe add an all new set of logging commands, to not confuse with the current logging behavior; keep and deprecate the old ones for users that were fine with those. (I was the one responsible for the death of 'logging level all everything', and I've stumped at least one user who now keeps patching it back in manually; let's not repeat that.) Maybe we can come up with more meaningful wording that more accurately indicate what is happening? But if the current command set suffices without confusion, we can also keep that, and maybe resurrect the 'logging level all everything'?? Here are the handles / use cases that come up -- I've embedded implementation choices and command names in this proposal, but it's intended as a blueprint to incorporate everyone else's bikesheds: 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? B) A "normal" logging behavior configured by the user. We need: 1) a command to set all categories at once 2) a command to tweak individual categories 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. 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). 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. F) Set a specific log context, and silence all messages (regardless of their logging category setting) unless they match the context filter: logging filter imsi 123456789123456 Though this feature has probably never been properly implemented through all code paths, it is potentially very powerful for live debugging. Especially with the new FSMs around everywhere, there is a good chance that we can fairly easily improve on the current 'logging filter foo' experience. During congress, I really yearned for this to work well. 0) In the current implementation, on each individual log message, this decides whether the context matches, and if not, the message is discarded. 1) Instead of discarding, we may want a level to reduce to. 2) Or maybe we want to leave the logging landscape unchanged, but lift the level for all logs that match the set context? 3) disable individual filters 4) disable all filters. This is currently 'logging filter all 1' but that is confusing, we could use a meaningful synonym, and separate from filters. G) toggle all logging in the telnet vty 1) silence logging (currently 'logging filter all 0', confusing) 2) continue logging (currently 'logging filter all 1', confusing) A bit of a meaningless image of different logging layers: level ^ Hardcoded defaults.. | ... - ====== =.... Normal logging landscape== | == .== ... ==... -- Temporary levels-- | -- =.... ...== - = | = -- ---- -=== |________________________> categories Same image with actual current logging overlayed: level ^ | ... # =###== =.... | == .== ... ==... ## Resulting levels ## | ## #.... ...## # = | # ## #### #=#= |________________________> categories - the hardcoded defaults are immutable. - the normal landscape can be freely chosen. - Some categories may have temporary tweaks. Where there are temporary tweaks, they take precedence as-is. The vty command ("make stronger" or "make weaker") decided whether to put a temporary level in place or not. Can you guys explain the current patch proposals in terms of above features? (like, use the capital letters A-G for reference) Feel free to change this vty transcript proposal i've tossed up as I went: ! A.1) hardcoded defaults logging hard-reset rsl,chan,msc logging hard-reset ! B) set normal categories ! B.1) all logging set notice all ! B.2) individual logging set notice rsl,chan,msc ! C) Temporarily reducing ! C.1) all logging reduce notice all ! C.2) individual logging reduce error l1p,nm,cc ! D) Temporarily increasing ! D.1) all logging increase info all ! D.2) individual logging increase debug mm,rr ! D.3) last one wins logging reduce error l1p,mm,rr logging increase debug mm,rr logging reduce notice rr ! result: l1p=error mm=debug rr=notice ! T) set temporary level unconditionally logging set-temp error all logging set-temp error mm,rr ! logging (recrease|induce) ;) ! E.3) remove temporary verbosity no logging reduce nm,cc no logging reduce all ! E.4) remove temporary silencing no logging increase nm,cc no logging increase all ! E.2) snap back to normal levels logging reset rsl,nm,rr ! E.1) ...for all categories logging reset all ! F.0) context filter logging filter imsi 123456789123456 ! F.1) choose context filter behavior logging filter-reduce error logging filter-discard ! F.2) logging filter-increase debug ! F.3) disable filter no logging filter imsi ! F.4) no logging filter ! G.1) logging [on] logging 1 ! G.2) no logging logging 0 Using a .TEXT argument, we could easily allow a space separator for category lists, as in "l1p mm cc". (nice would be to invent a VTY argument type that allows any number of the same kind, so far we have weird constructs like seen in bsc_vty.c, cfg_bts_codec0_cmd thru cfg_bts_codec4_cmd each with a different nr of same argument) A test program should define logging categories and a context filter, issue each of above commands and then log once all across each level and category to see what logging we still see. As a final step, we should figure out how the current logging commands match these features, and make them still do the things they always did as best as makes sense. What do you guys think? About bikesheds: if we can't agree, we could put out a patch contest, where everyone that cares implements a proposal, and we vote in the end. I hope we don't waste time by deadlocking in the end ;) ~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/20180725/5081dbc4/attachment.bin>