On 09/20/2017 04:32 AM, Masahiro Yamada wrote:
Hi Simon,
2017-09-17 6:23 GMT+09:00 Simon Glass sjg@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