[PATCH 1/1] log: output for CONFIG_LOG=n

[Heinrich Schuchardt]

On 2/11/20 12:13 AM, Simon Glass wrote:
> Hi Heinrich,
>
> On Sun, 9 Feb 2020 at 15:33, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>>
>> On 2/9/20 11:21 PM, Sean Anderson wrote:
>>> On 2/9/20 4:59 PM, Heinrich Schuchardt wrote:
>>>> If CONFIG_LOG=n, we should still output errors, warnings, notices, infos,
>>>> and for DEBUG=1 also debug messages.
>>>>
>>>> Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de>
>>>
>>> Why not just change the default for CONFIG_LOG to y? This is effectively
>>> the same, except it still allows users to completely disable logging
>>> altogether.
>>>
>>> --Sean
>>>
>>
>
> Reviewed-by: Simon Glass <sjg at chromium.org>
>
>> I have tested your suggestion for qemu_arm64_defconfig:
>>
>> Without my patch and CONFIG_LOG=n:
>>
>> u-boot.bin 664200 bytes
>>
>> With my patch and CONFIG_LOG=n:
>>
>> u-boot.bin 664432 bytes
>>
>> Without my patch but with CONFIG_LOG=y and CONFIG_CONSOLE=y:
>
> What is CONFIG_CONSOLE?

This is a typo. It should be CONFIG_LOG_CONSOLE.

Thanks for reviewing.

>
>>
>> u-boot.bin 666648 bytes
>>
>> So your suggestion consumes 2216 additional bytes to produce the
>> essentially the same console output.
>
> OK. That is a lot more than I thought.
>
> I'm not sure if it is possible to update the log test to cover your new case?

The current log test case in not a close fit, as filtering will be
irrelevant.

It should be possible to create a test using console recording
(CONFIG_CONSOLE_RECORD=y).

Looking at test/dm/test-main.c it seems that you once wanted to use
console recording in a test but I could not identify any test actually
using it up to now.

Best regards

Heinrich

>
>>
>> IMHO CONFIG_LOG=y is currently only helpful in the following situation:
>>
>> * You are debugging your board and want to interactively change
>>     logging levels.
>> * You want to log to a remote syslog server.
>
> Actually a major reason is that you want the full firmware log to be
> reported to Linux so you can check for warnings, etc. However we don't
> currently support this.
>
> Regards,
> Simon
>