On 21.12.2015 15:52, Holger Freyther wrote:
On 21 Dec 2015, at 15:13, Jacob Erlbeck jerlbeck@sysmocom.de wrote:
Hi Holger,
On 21.12.2015 14:17, Holger Freyther wrote:
On 17 Nov 2015, at 11:52, Jacob Erlbeck jerlbeck@sysmocom.de wrote:
/* This might get logged (ignoring filters) */What is the reasoning for this part?
I wanted to have a weaker criterion than 'return true if and only if something would be logged' to be more flexible when it comes to optimization. I had lookup tables in mind which cache the max level per facility, and which get updated when e.g. log_set_log_level is called. This would be O(1) consuming just a few CPU cycles per log, but would not help when filtering is used.
And I didn't really understand filters when I wrote that commit. Including them into the log_check_level decision definitely makes sense if I want to use log DEBUG level stuff on an embedded or high load system.
Okay maybe I am missing a case here but it feels like we don't save anything by not calling it. So if the log level is good for output we return 1 and then do the full work. It doesn't really matter which function we do this work in.
And as this doesn't matter we can leave it out. I posted a patch that removes the selection criteria and subsys code clone.
Hmm, there seems to be some misunderstanding. While thinking about the filter stuff again, I liked the idea to include the filter test into log_check_level. It would made it possible to DEBUG-log e.g. single subscribers or MS without rendering the application unusable if the load were high (and filters really supported). So please don't remove it from your patch.
Jacob