From 9ad7a6c25c7142a46fe4b811c13bc3280c4bb27f Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Wed, 20 Jan 2021 20:10:53 -0700 Subject: log: Handle line continuation When multiple log() calls are used which don't end in newline, the log prefix is prepended multiple times in the same line. This makes the output look strange. Fix this by detecting when the previous log record did not end in newline. In that case, setting a flag. Drop the unused BUFFSIZE in the test while we are here. As an example implementation, update log_console to check the flag and produce the expected output. Signed-off-by: Simon Glass --- doc/develop/logging.rst | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'doc/develop') diff --git a/doc/develop/logging.rst b/doc/develop/logging.rst index 60c18c5b3a..622ad6ad1a 100644 --- a/doc/develop/logging.rst +++ b/doc/develop/logging.rst @@ -96,6 +96,22 @@ Also debug() and error() will generate log records - these use LOG_CATEGORY as the category, so you should #define this right at the top of the source file to ensure the category is correct. +Generally each log format_string ends with a newline. If it does not, then the +next log statement will have the LOGRECF_CONT flag set. This can be used to +continue the statement on the same line as the previous one without emitting +new header information (such as category/level). This behaviour is implemented +with log_console. Here is an example that prints a list all on one line with +the tags at the start: + +.. code-block:: c + + log_debug("Here is a list:"); + for (i = 0; i < count; i++) + log_debug(" item %d", i); + log_debug("\n"); + +Also see the special category LOGL_CONT and level LOGC_CONT. + You can also define CONFIG_LOG_ERROR_RETURN to enable the log_ret() macro. This can be used whenever your function returns an error value: -- cgit From 7bd06587decafabb56f68de3ae87adb4c49ca8db Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Wed, 20 Jan 2021 20:10:54 -0700 Subject: log: Add return-checking macros for 0 being success The existing log_ret() and log_msg_ret() macros consider an error to be less than zero. But some function may return a positive number to indicate a different kind of failure. Add macros to check for that also. Signed-off-by: Simon Glass --- doc/develop/logging.rst | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) (limited to 'doc/develop') diff --git a/doc/develop/logging.rst b/doc/develop/logging.rst index 622ad6ad1a..f4e925048e 100644 --- a/doc/develop/logging.rst +++ b/doc/develop/logging.rst @@ -117,11 +117,24 @@ can be used whenever your function returns an error value: .. code-block:: c - return log_ret(uclass_first_device(UCLASS_MMC, &dev)); + return log_ret(uclass_first_device_err(UCLASS_MMC, &dev)); This will write a log record when an error code is detected (a value < 0). This can make it easier to trace errors that are generated deep in the call stack. +The log_msg_ret() variant will print a short string if CONFIG_LOG_ERROR_RETURN +is enabled. So long as the string is unique within the function you can normally +determine exactly which call failed: + +.. code-block:: c + + ret = gpio_request_by_name(dev, "cd-gpios", 0, &desc, GPIOD_IS_IN); + if (ret) + return log_msg_ret("gpio", ret); + +Some functions return 0 for success and any other value is an error. For these, +log_retz() and log_msg_retz() are available. + Convenience functions ~~~~~~~~~~~~~~~~~~~~~ -- cgit