> On 28 Dec 2015, at 14:35, Pierre Baudry wrote:
>
> Hello list,
Hi!
> Is this patch still considered for a merge ?
sure, I send an updated version to the list, feel free to review it and provide
some comments.
holger
Hello list,
Is this patch still considered for a merge ?
It seems that embedded systems will largely benefit from this early
check. It may improve osmo-pcu performance, as discussed in "osmo-bts
/ osmo-pcu profiling results" thread but also all binaries running on
low resources systems.
I have no
On 21.12.2015 15:52, Holger Freyther wrote:
>
>> On 21 Dec 2015, at 15:13, Jacob Erlbeck wrote:
>>
>> Hi Holger,
>>
>> On 21.12.2015 14:17, Holger Freyther wrote:
>>>
On 17 Nov 2015, at 11:52, Jacob Erlbeck wrote:
>>
+ /* This might get logged (ignoring filters) */
>>>
>>> Wha
> On 21 Dec 2015, at 15:13, Jacob Erlbeck wrote:
>
> Hi Holger,
>
> On 21.12.2015 14:17, Holger Freyther wrote:
>>
>>> On 17 Nov 2015, at 11:52, Jacob Erlbeck wrote:
>
>>> + /* This might get logged (ignoring filters) */
>>
>> What is the reasoning for this part?
>
> I wanted to
Hi Holger,
On 21.12.2015 14:17, Holger Freyther wrote:
>
>> On 17 Nov 2015, at 11:52, Jacob Erlbeck 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 wou
> On 17 Nov 2015, at 11:52, Jacob Erlbeck wrote:
Hi Jacob,
I am in favour of such a patch to prevent doing work (formatting arguments)
when it will not be used.
>
> + /* This might get logged (ignoring filters) */
What is the reasoning for this part?
The below does not work ye
This commit adds this predicate function which can be used to
avoid the execution of code if a certain log level is not enabled.
The function will only return 0 (false), if it is sure that a logging
call for the same facility and level will not produce any output.
This safety criterion shall ensur
