On 09/20/2017 04:32 AM, Masahiro Yamada wrote: > 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, ...) >
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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
