From: Sascha Hauer <s.hauer@pengutronix.de>
To: Eugen Wiens <eugen.wiens@jumo.net>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH] added colored print out of log levels
Date: Tue, 13 Feb 2018 09:37:17 +0100 [thread overview]
Message-ID: <20180213083717.ckxlikbsibt4a2y2@pengutronix.de> (raw)
In-Reply-To: <20180209122845.4113-1-eugen.wiens@jumo.net>
HI Eugen,
On Fri, Feb 09, 2018 at 01:28:45PM +0100, Eugen Wiens wrote:
> When the system is booting the warnings and errors are not be quickly discovered.
> With this improvement the errors are colored red, the warnings yellow and the notices blue.
I like this because I like colors ;)
However, some people do not. Can we make this honour the value of the
global.allow_color variable? This variable is currently only used in the
environment, so we would have to move it to C code by adding a
globalvar_add_simple_bool().
>
> Signed-off-by: Eugen Wiens <eugen.wiens@jumo.net>
> ---
> common/Kconfig | 8 ++++++++
> common/console_common.c | 29 ++++++++++++++++++++++++++++-
> 2 files changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/common/Kconfig b/common/Kconfig
> index 57418ca..461ad35 100644
> --- a/common/Kconfig
> +++ b/common/Kconfig
> @@ -1000,6 +1000,14 @@ config DEFAULT_LOGLEVEL
> 7 debug-level messages (debug)
> 8 verbose debug messages (vdebug)
>
> +config PRINT_COLORED_LOG_LEVEL
> + prompt "enable colored printing of the log level"
> + bool
> + default n
> + help
> + Enable the print out of the colored log level.
I don't think it's worth having an extra config option for this.
If we get concerned about the code size, then we should rather
add a global color control Kconfig option and let everything color
related depend on this.
Something like:
config CONSOLE_ALLOW_COLOR
prompt "Allow colored console output"
bool
static unsigned int allow_color;
bool __console_allow_color(void)
{
return allow_color;
}
Some initcall:
globalvar_add_simple_bool("allow_color", &allow_color);
include/:
static inline bool console_allow_color(void)
{
if (!IS_ENABLED(CONFIG_CONSOLE_ALLOW_COLOR))
return false;
return __console_allow_color();
}
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2018-02-13 8:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-09 12:28 Eugen Wiens
2018-02-13 8:37 ` Sascha Hauer [this message]
[not found] <OFB3F14132.C502B498-ONC1258234.0028C966-C1258234.0028E812@LocalDomain>
2018-02-14 7:32 ` Sascha Hauer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180213083717.ckxlikbsibt4a2y2@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=eugen.wiens@jumo.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox