[U-Boot] [PATCH 00/13] log: Add a new logging feature

[Simon Glass]

Hi Heinrich,

On 20 September 2017 at 14:20, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> On 09/20/2017 04:32 AM, Masahiro Yamada wrote:
>> Hi Simon,
>>
>>
>> 2017-09-17 6:23 GMT+09:00 Simon Glass <sjg at chromium.org>:
>>> U-Boot currently has fairly rudimentary logging features. A basic printf()
>>> provides console output and debug() provides debug output which is
>>> activated if DEBUG is defined in the file containing the debug()
>>> statements.
>>>
>>> It would be useful to have a few more features:
>>>
>>> - control of debug output at runtime, so  problems can potentially be
>>> debugged without recompiling U-Boot
>>> - control of which subsystems output debug information, so that (for
>>> example) it is possible to enable debugging for MMC or SATA at runtime
>>> - indication of severity with each message, so that the user can control
>>> whether just errors are displayed, warnings, or all debug messages
>>> - sending logging information to different destinations, such as console,
>>> memory, linux, etc,
>>>
>>> At present U-Boot has a logbuffer feature which records output in a memory
>>> buffer for later display or storage. This is useful but is not at present
>>> enabled for any board.
>>>
>>> This series introduced a new logging system which supports:
>>> - various log levels from panic to debug
>>> - log categories including all uclasses and a few others
>>> - log drivers to which all log records can be sent
>>> - log filters which control which log records make it to which drivers
>>>
>>> Enabling logging with the default options does not add much to code size.
>>> By default the maximum recorded log level is LOGL_INFO, meaning that debug
>>> messages (and above) are discarded a build-time. Increasing this level
>>> provides more run-time flexibility to enable/disable logging at the cost
>>> of increased code size.
>>>
>>> This feature is by no means finished. The README provides a long list of
>>> features and clean-ups that could be done. But hopefully this is a
>>> starting point for improving this important area in U-Boot.
>>>
>>> The series is available at u-boot-dm/log-working
>>
>>
>>
>> As you notice, this series has lots of conflicts with my clean-up works.
>>
>> The lesson we leaned is we should prepare Linux-compatible APIs where possible,
>> instead of inventing similar ones for our own.
>> Otherwise, people would start to sprinkle compat macros/headers everywhere.
>>
>> In this sense, this series introduce similar, but different
>> interfaces.
>>
>> If you want the log interface, could you implement it
>> as a back-end of printk() (after my clean-ups) ?
>> Users can use printk(), or more preferably pr_()
>> to call the log API.
>>
>>
>> If CONFIG_LOG is disabled, printk() falls back to printf(),
>> i.e. the log is immediately printed to the console.
>>
>> If CONFIG_LOG is enabled, printk() sends the log message
>> to the log facility you are implementing.
>>
>>
>> I am not sure how much demand exists for category/file filters.
>> Having both of them (or even one of them) might be over-implementation.
>>
>> I do not like the category filter because I do not want to see
>>    log(LOGC_BOARD, ...)
>>
>
> Filtering by category is a good idea. I have been developing parts of
> the EFI API implementation. There it showed up to be a necessity to
> disable debug output for events (occuring dozens of times per
> millisecond). Network services will fail if timeouts occur due to too
> many log message passed over a slow serial console.
>
> As fine grained control is currently missing I had to spray
>   #undefine _DEBUG
>   #define _DEBUG 0
>   ...
>   #define _DEBUG 1
> all over the code.
>
> Other codes (e.g. iPXE) can enable debugging per module with different
> verbosity levels, cf. http://ipxe.org/download#debug_builds .

Actually I quite like those levels:

- Enable basic debug messages
- Enable verbose debug messages (e.g. one message per event)
- Enable extra-verbose debug messages (e.g. one message per byte)
- Enable I/O tracing (e.g. one message per readl()/writel() call)

This seems a lot better than having just a 'debug' level.

Regards,
Simon