On 21 Dec 2015, at 15:13, Jacob Erlbeck
<jerlbeck(a)sysmocom.de> wrote:
Hi Holger,
On 21.12.2015 14:17, Holger Freyther wrote:
> On 17 Nov 2015, at 11:52, Jacob Erlbeck <jerlbeck(a)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.