Hi Simon,
2017-09-17 6:23 GMT+09:00 Simon Glass <s...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
