Colored kernel message output
Let's work more on Linux's cuteness! [http://lkml.org/lkml/2007/10/4/431]

The following patch makes it possible to give kernel messages a

selectable color which helps to distinguish it from other noise,

such as boot messages. NetBSD has it, OpenBSD has it, FreeBSD to some

extent, so I think Linux should too.
Inspired by cko (http://freshmeat.net/p/cko/), but independently

written, later contributed forth and back.
Already posted at: http://lkml.org/lkml/2007/4/1/162
Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
---

 drivers/char/Kconfig |   29 +++++++++++++++++++++++++++++

 drivers/char/vt.c    |   14 ++++++++++++++

 2 files changed, 43 insertions(+)
Index: linux-2.6.23/drivers/char/Kconfig

===================================================================

--- linux-2.6.23.orig/drivers/char/Kconfig

+++ linux-2.6.23/drivers/char/Kconfig

@@ -58,6 +58,35 @@ config VT_CONSOLE
 	  If unsure, say Y.
+config VT_PRINTK_COLOR

+	hex "Colored kernel message output"

+	range 0x00 0xFF

+	depends on VT_CONSOLE

+	default 0x17

+	---help---

+	This option will give you ability to change the color of

+	kernel messages printed to the console.

+

+	The value you need to enter here is the ASCII color value

+	composed (OR'ed) by one foreground color, one background

+	color and any number of attributes as follows:

+

+	Foreground:

+	0x00=black, 0x01=blue, 0x02=green, 0x03=green,

+	0x04=red, 0x05=magenta, 0x06=brown, 0x07=gray

+

+	Background:

+	0x00=black, 0x10=blue, 0x20=green, 0x30=green,

+	0x40=red, 0x50=magenta, 0x60=brown, 0x70=gray

+

+	Attributes:

+	0x08=highlight foreground

+

+	Thus, 0x17 will yield gray-on-blue like in OpenBSD and

+	0x02 green-on-black like in NetBSD.

+	Using "highlight foreground" is said not work when you use

+	VGA Console (Framebuffer not affected) with a 512-glyph font.

+

 config HW_CONSOLE

 	bool

 	depends on VT && !S390 && !UML

Index: linux-2.6.23/drivers/char/vt.c

====================...
[ message continues ]

Pretty interesting feature. I modified your lastest patch a little bit

so now you can set the message color for each log level in the kernel

config.
diff -ruN linux-2.6.23.orig/arch/x86_64/kernel/early_printk.c

linux-2.6.23/arch/x86_64/kernel/early_printk.c

--- linux-2.6.23.orig/arch/x86_64/kernel/early_printk.c	2007-10-02

05:24:52.000000000 +0200

+++ linux-2.6.23/arch/x86_64/kernel/early_printk.c	2007-10-06

23:00:39.000000000 +0200

@@ -20,7 +20,8 @@

 static int max_ypos = 25, max_xpos = 80;

 static int current_ypos = 25, current_xpos = 0;
-static void early_vga_write(struct console *con, const char *str, unsigned n)

+static void early_vga_write(struct console *con, const char *str, unsigned n,

+                            unsigned int loglevel)

 {

 	char c;

 	int  i, k, j;

@@ -89,7 +90,8 @@

 	return timeout ? 0 : -1;

 }
-static void early_serial_write(struct console *con, const char *s, unsigned n)

+static void early_serial_write(struct console *con, const char *s, unsigned n,

+                               unsigned int loglevel)

 {

 	while (*s && n-- > 0) {

 		if (*s == '\n')

@@ -185,7 +187,8 @@

 	simnow_fd = simnow(XOPEN, (unsigned long)fn, O_WRONLY|O_APPEND|O_CREAT, 0644);

 }
-static void simnow_write(struct console *con, const char *s, unsigned n)

+static void simnow_write(struct console *con, const char *s, unsigned n,

+                         unsigned int loglevel)

 {

 	simnow(XWRITE, simnow_fd, (unsigned long)s, n);

 }

@@ -209,7 +212,7 @@
 	va_start(ap,fmt);

 	n = vscnprintf(buf,512,fmt,ap);

-	early_console->write(early_console,buf,n);

+	early_console->write(early_console, buf, n, 0);

 	va_end(ap);

 }
diff -ruN linux-2.6.23.orig/drivers/char/Kconfig

linux-2.6.23/drivers/char/Kconfig

--- linux-2.6.23.orig/drivers/char/Kconfig	2007-10-02 05:24:52.000000000 +0200

+++ linux-2.6.23/drivers/char/Kconfig	2007-10-06 23:06:55.000000000 +0200

@@ -58,6 +58,111 @@
 	  If unsure, say Y.
+config VT_CKO

+	bool "Colored kernel message ...
[ message continues ]

I like it, although having a boot option would be nice (I have a friend

with color perception issues).
I start my root xterm in white on blue for identification, so color

coding sounds like a great idea to me.
--

Bill Davidsen <davidsen@tmr.com>

   "We have more to fear from the bungling of the incompetent than from

the machinations of the wicked."  - from Slashdot

-

sysfs attributes can be set at boot time (and not only that).

Here, try the "davej's salad" configuration :-)
	vt.default_red=0,192,128,170,0,170

	vt.default_grn=0,0,170,128,64,0

	vt.default_blu=0,0,0,0,128,128
This has nothing to do with xterms, this is "VGA color console" only.

xterm config is in /usr/share/X11/app-defaults/XTerm-color.

-

Try reparsing that... I said I use color coding in root xterm, so I am

generally in favor of the color coding concept to make important

messages obvious. Is that clearer?
--

Bill Davidsen <davidsen@tmr.com>

   "We have more to fear from the bungling of the incompetent than from

the machinations of the wicked."  - from Slashdot

-

A reparse did it.

-

looks really good to me!
Reviewed-by: Ingo Molnar <mingo@elte.hu>
small nit:
+       vc->vc_color = printk_color;

+       update_attr(vc);
that should be in a set_vc_color() function and the new code should do:
+	set_vc_color(vc, vc->vc_color);
(and same at the other places that call update_attr() as well)
feature request: would be interesting to have a color table (defined in

the .config) dependent on message loglevel. That way KERN_CRIT messages

could be red, KERN_INFO ones white, etc.
	Ingo

-

This approach in GIGO-like, IMHO. Ugliness of (default) boot process

messaging itself can and must be solved in the userspace. I don't know if

anybody read sub-thread about size reduction by moving static printk

string to userspace "message codes" (there were one more person than me,

but still).
The main problem, is the very narrow perspective of such "kernel"
See? In the userspace one can make anything freely, try do it in the

Linux kernel. With userspace {codes, messages} -> messages tool, any

console printing frontend is possible. Of course, when kernel OOPes

before or in early userspace, where nothing other than photo viva is
Is it possible to have a macro for this, which will be

`do { } while(0)' in case of "NO, thanks" configuration?
--

-o--=O`C

 #oo'L O

<___=E M

-

On Sat, Oct 06, 2007 at 01:08:35PM +0200, Ingo Molnar wrote:
 > feature request: would be interesting to have a color table (defined in

 > the .config) dependent on message loglevel. That way KERN_CRIT messages

 > could be red, KERN_INFO ones white, etc.
If we do this, please let there be a CONFIG_ option to turn it off (and that

should probably be the default too).  Bootup text looking like a fruit salad

doesn't really sound like something that will make debugging any easier.
	Dave
--

http://www.codemonkey.org.uk

-

I'm certainly not a native English writer, though I think it

should be "composed of" or maybe "composed from".
I'd say "HF is known not to work with VGA console" or just

"HF doesn't work with VGA console".
I wonder how accurate is it.

--

Krzysztof Halasa

-

ANSI:
\e[31m R--

\e[32m G--

\e[33m RG- (yellow)

\e[34m --B

\e[35m R-B (magenta)

\e[36m -GB (cyan)

\e[37m RGB (white)
ASCII:
1 --B blue

2 -G- green

3 -GB cyan

4 R-- red
...
e.g. just the other way around. 0x17 is gray-on-blue, what I use,
Since I do not use 512-glyph fonts, I do not know.

I suppose no, since that is what is written in the manpages or so.
With FB where the hardware draws the font, I do not know either,

I suppose yes.
With FB where the software draws the font (read: fbiterm with CJK),

it worked as usual, last time I tested.

-

Actually I meant "how accurate my remarks are" :-)
Not convinced WRT ASCII color codes, though. ASCII doesn't contain

codes for changing colors. Perhaps some specific "extended ASCII"?

--

Krzysztof Halasa

-

Start up QBasic, issue

	COLOR 1

=> blue.
Apply said patch, issue

	vt.printk_color=0x01

=> you get what?
So! :)

-

What we see here might not be "ASCII", but "VGA-specific color values".

It's just that I call it ASCII since it's the mirrored opposite of ANSI.

-

I see. Then perhaps "VGA color value" would be better.

--

Krzysztof Halasa

-

I like it. A somewhat related nice feature would be to print different

loglevels with different colors.
Cheers,

Emil.

-

Shouldn't the default at least be what we already had?  Somehow grey on

blue sounds pretty hard to read to me.
--

Len Sorensen

-

Indeed it should be 0x07, should it go in.

Otherwise the openbsd camp might start another flamewar.
(On a personal note, would 0x1F work better for you?)

-

No, I actually find most things hard to read on a blue background.

Besides black uses less power on a CRT (and probably OLED as well)

monitor.  LCDs probably don't care.  :)
--

Len Sorensen

-

Ah you seem to be a proponent of http://www.blackgoogle.com/

then :-)  Unfortunately, it seems like Xft uses Grayscale AA

(http://antigrain.com/research/font_rasterization/index.html)

so black background make the font look thinner.

-

I was mainly thinking someone with a server with a screen showing their

console might like to not make too much heat in the server room.
Google can be solved by simply closing the browser window. :)
--

Len Sorensen

-

"Ha, ok, I see where you're going with this one."
This patch is perfectly suited to reduce heat at home and in the server

room, especially during kernel development and debugging, but the

average kernel usage already pays off. Just add vt.printk_color=0x08

and all your kernel messages and oopses will be printed using low-power

electrons. Extremely useful on SGI Altix 4700, which does print a lot

(number of CPU cores), or SunFire X4500 (number of disks). Even if not

using one of these systems, CKO can contribute to the lower power usage

of PetaBox™ [http://www.archive.org/web/petabox.php]... ;-)

-