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

[Heinrich Schuchardt]

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 .

Regards

Heinrich