Hi Heinrich, On 20 September 2017 at 14:20, Heinrich Schuchardt <xypron.g...@gmx.de> wrote: > 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 .
Actually I quite like those levels: - Enable basic debug messages - Enable verbose debug messages (e.g. one message per event) - Enable extra-verbose debug messages (e.g. one message per byte) - Enable I/O tracing (e.g. one message per readl()/writel() call) This seems a lot better than having just a 'debug' level. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot