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

[Masahiro Yamada]

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, ...)




-- 
Best Regards
Masahiro Yamada