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 <[email protected]>
---
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
===================================================================
--- linux-2.6.23.orig/drivers/char/vt.c
+++ linux-2.6.23/drivers/char/vt.c
@@ -73,6 +73,7 @@
*/
#include <linux/module.h>
+#include <linux/moduleparam.h>
#include <linux/types.h>
#include <linux/sched.h>
#include <linux/tty.h>
@@ -2348,6 +2349,9 @@ struct tty_driver *console_driver;
#ifdef CONFIG_VT_CONSOLE
+static unsigned int printk_color = CONFIG_VT_PRINTK_COLOR;
+module_param(printk_color, uint, S_IRUGO | S_IWUSR);
+
/*
* Console on virtual terminal
*
@@ -2388,12 +2392,16 @@ static void vt_console_print(struct cons
hide_cursor(vc);
start = (ushort *)vc->vc_pos;
+ vc->vc_color = printk_color;
+ update_attr(vc);
/* Contrived structure to try to emulate original need_wrap behaviour
* Problems caused when we have need_wrap set on '\n' character */
while (count--) {
c = *b++;
if (c == 10 || c == 13 || c == 8 || vc->vc_need_wrap) {
+ vc->vc_color = vc->vc_def_color;
+ update_attr(vc);
if (cnt > 0) {
if (CON_IS_VISIBLE(vc))
vc->vc_sw->con_putcs(vc, start, cnt, vc->vc_y, vc->vc_x);
@@ -2406,6 +2414,8 @@ static void vt_console_print(struct cons
bs(vc);
start = (ushort *)vc->vc_pos;
myx = vc->vc_x;
+ vc->vc_color = printk_color;
+ update_attr(vc);
continue;
}
if (c != 13)
@@ -2413,6 +2423,8 @@ static void vt_console_print(struct cons
cr(vc);
start = (ushort *)vc->vc_pos;
myx = vc->vc_x;
+ vc->vc_color = printk_color;
+ update_attr(vc);
if (c == 10 || c == 13)
continue;
}
@@ -2434,6 +2446,8 @@ static void vt_console_print(struct cons
vc->vc_need_wrap = 1;
}
}
+ vc->vc_color = vc->vc_def_color;
+ update_attr(vc);
set_cursor(vc);
quit:
On Fri, Oct 05, 2007 at 09:13:40PM +0200, Jan Engelhardt wrote:
> +config VT_PRINTK_COLOR
> + hex "Colored kernel message output"
> + range 0x00 0xFF
> + depends on VT_CONSOLE
> + default 0x17
Shouldn't the default at least be what we already had? Somehow grey on
blue sounds pretty hard to read to me.
--
Len Sorensen
On Oct 5 2007 15:19, Lennart Sorensen wrote:
>On Fri, Oct 05, 2007 at 09:13:40PM +0200, Jan Engelhardt wrote:
>> +config VT_PRINTK_COLOR
>> + hex "Colored kernel message output"
>> + range 0x00 0xFF
>> + depends on VT_CONSOLE
>> + default 0x17
>
>Shouldn't the default at least be what we already had? Somehow grey on
>blue sounds pretty hard to read to me.
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?)
On Fri, Oct 05, 2007 at 09:21:57PM +0200, Jan Engelhardt wrote:
> 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
On Oct 5 2007 15:24, Lennart Sorensen wrote:
>On Fri, Oct 05, 2007 at 09:21:57PM +0200, Jan Engelhardt wrote:
>> 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. :)
>
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.
On Fri, Oct 05, 2007 at 09:32:11PM +0200, Jan Engelhardt wrote:
> 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
On Oct 5 2007 15:43, Lennart Sorensen wrote:
>On Fri, Oct 05, 2007 at 09:32:11PM +0200, Jan Engelhardt wrote:
>> 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.
"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]... ;-)
Hi Jan,
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Jan
> Engelhardt
> Sent: Friday, October 05, 2007 2:14 PM
> To: Linux Kernel Mailing List
> Cc: Andrew Morton
> Subject: [PATCH] Cute feature: colored printk output
>
>
> 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 <[email protected]>
I like it. A somewhat related nice feature would be to print different
loglevels with different colors.
Cheers,
Emil.
Jan Engelhardt <[email protected]> writes:
> + The value you need to enter here is the ASCII color value
ASCII color value? ANSI perhaps?
> + composed (OR'ed) by one foreground color, one background
> + color and any number of attributes as follows:
I'm certainly not a native English writer, though I think it
should be "composed of" or maybe "composed from".
"one" doesn't sound well in my ears, either.
> + Using "highlight foreground" is said not work when you use
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
On Oct 6 2007 01:22, Krzysztof Halasa wrote:
>Jan Engelhardt <[email protected]> writes:
>
>> + The value you need to enter here is the ASCII color value
>
>ASCII color value? ANSI perhaps?
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,
so it's ASCII actually. Quite confusing, yes. :-/
>composed ...
yes, should reword that.
>> + Using "highlight foreground" is said not work when you use
>
>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.
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.
Jan Engelhardt <[email protected]> writes:
>>I wonder how accurate is it.
>
> Since I do not use 512-glyph fonts, I do not know.
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
On Oct 6 2007 02:10, Krzysztof Halasa wrote:
>Jan Engelhardt <[email protected]> writes:
>
>>>I wonder how accurate is it.
>>
>> Since I do not use 512-glyph fonts, I do not know.
>
>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"?
Start up QBasic, issue
COLOR 1
=> blue.
Apply said patch, issue
vt.printk_color=0x01
=> you get what?
So! :)
On Oct 6 2007 02:23, Jan Engelhardt wrote:
>>
>>Not convinced WRT ASCII color codes, though. ASCII doesn't contain
>>codes for changing colors. Perhaps some specific "extended ASCII"?
>
>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.
* Jan Engelhardt <[email protected]> wrote:
> 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 <[email protected]>
looks really good to me!
Reviewed-by: Ingo Molnar <[email protected]>
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
Jan Engelhardt <[email protected]> writes:
> 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
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
* Sat, 6 Oct 2007 13:08:35 +0200
> * Jan Engelhardt <[email protected]> wrote:
>
>> 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
Only boot time selectable? Then write so, please.
>> 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.
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"
functionality:
> 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
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
possible, nobody should care about "Linux's cuteness!"
>> 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 <[email protected]>
>
> looks really good to me!
>
> Reviewed-by: Ingo Molnar <[email protected]>
>
> 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)
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
Jan Engelhardt wrote:
> 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.
>
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 <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
On Oct 6 2007 15:53, Bill Davidsen wrote:
> Jan Engelhardt wrote:
>> 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.
>>
> I like it, although having a boot option would be nice (I have a friend with
> color perception issues).
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
vt.printk_color=1,1,1,1,5,3,2
> I start my root xterm in white on blue for identification, so color coding
> sounds like a great idea to me.
This has nothing to do with xterms, this is "VGA color console" only.
xterm config is in /usr/share/X11/app-defaults/XTerm-color.
On 10/5/07, Jan Engelhardt <[email protected]> wrote:
>
> 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
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 output"
+ depends on VT_CONSOLE
+ ---help---
+ This option enables kernel messages to be emitted in
+ colors other than the default.
+
+ The color value you need to enter is composed (OR-ed)
+ of a foreground and a background color.
+
+ Foreground:
+ 0x00 = black, 0x08 = dark gray,
+ 0x01 = red, 0x09 = light red,
+ 0x02 = green, 0x0A = light green,
+ 0x03 = brown, 0x0B = yellow,
+ 0x04 = blue, 0x0C = light blue,
+ 0x05 = magenta, 0x0D = light magenta,
+ 0x06 = cyan, 0x0E = light cyan,
+ 0x07 = gray, 0x0F = white,
+
+ (Foreground colors 0x08 to 0x0F do not work when a VGA
+ console font with 512 glyphs is used.)
+
+ Background:
+ 0x00 = black, 0x40 = blue,
+ 0x10 = red, 0x50 = magenta,
+ 0x20 = green, 0x60 = cyan,
+ 0x30 = brown, 0x70 = gray,
+
+ For example, 0x1F would yield white on red.
+
+ If unsure, say N.
+
+config VT_PRINTK_EMERG_COLOR
+ hex "Emergency messages color"
+ range 0x00 0xFF
+ depends on VT_CKO
+ default 0x07
+ ---help---
+ This option defines with which color kernel emergency messages will
+ be printed to the console.
+
+config VT_PRINTK_ALERT_COLOR
+ hex "Alert messages color"
+ range 0x00 0xFF
+ depends on VT_CKO
+ default 0x07
+ ---help---
+ This option defines with which color kernel alert messages will
+ be printed to the console.
+
+config VT_PRINTK_CRIT_COLOR
+ hex "Critical messages color"
+ range 0x00 0xFF
+ depends on VT_CKO
+ default 0x07
+ ---help---
+ This option defines with which color kernel critical messages will
+ be printed to the console.
+
+config VT_PRINTK_ERR_COLOR
+ hex "Error messages color"
+ range 0x00 0xFF
+ depends on VT_CKO
+ default 0x07
+ ---help---
+ This option defines with which color kernel error messages will
+ be printed to the console.
+
+config VT_PRINTK_WARNING_COLOR
+ hex "Warning messages color"
+ range 0x00 0xFF
+ depends on VT_CKO
+ default 0x07
+ ---help---
+ This option defines with which color kernel warning messages will
+ be printed to the console.
+
+config VT_PRINTK_NOTICE_COLOR
+ hex "Notice messages color"
+ range 0x00 0xFF
+ depends on VT_CKO
+ default 0x07
+ ---help---
+ This option defines with which color kernel notice messages will
+ be printed to the console.
+
+config VT_PRINTK_INFO_COLOR
+ hex "Information messages color"
+ range 0x00 0xFF
+ depends on VT_CKO
+ default 0x07
+ ---help---
+ This option defines with which color kernel information messages will
+ be printed to the console.
+
+config VT_PRINTK_DEBUG_COLOR
+ hex "Debug messages color"
+ range 0x00 0xFF
+ depends on VT_CKO
+ default 0x07
+ ---help---
+ This option defines with which color kernel debug messages will
+ be printed to the console.
+
config HW_CONSOLE
bool
depends on VT && !S390 && !UML
diff -ruN linux-2.6.23.orig/drivers/char/vt.c linux-2.6.23/drivers/char/vt.c
--- linux-2.6.23.orig/drivers/char/vt.c 2007-10-02 05:24:52.000000000 +0200
+++ linux-2.6.23/drivers/char/vt.c 2007-10-06 23:06:55.000000000 +0200
@@ -73,6 +73,7 @@
*/
#include <linux/module.h>
+#include <linux/moduleparam.h>
#include <linux/types.h>
#include <linux/sched.h>
#include <linux/tty.h>
@@ -2344,16 +2345,44 @@
#ifdef CONFIG_VT_CONSOLE
+#ifdef CONFIG_VT_CKO
+static unsigned int printk_color[8] __read_mostly = {
+ CONFIG_VT_PRINTK_EMERG_COLOR, /* KERN_EMERG */
+ CONFIG_VT_PRINTK_ALERT_COLOR, /* KERN_ALERT */
+ CONFIG_VT_PRINTK_CRIT_COLOR, /* KERN_CRIT */
+ CONFIG_VT_PRINTK_ERR_COLOR, /* KERN_ERR */
+ CONFIG_VT_PRINTK_WARNING_COLOR, /* KERN_WARNING */
+ CONFIG_VT_PRINTK_NOTICE_COLOR, /* KERN_NOTICE */
+ CONFIG_VT_PRINTK_INFO_COLOR, /* KERN_INFO */
+ CONFIG_VT_PRINTK_DEBUG_COLOR, /* KERN_DEBUG */
+};
+module_param_array(printk_color, uint, NULL, S_IRUGO | S_IWUSR);
+
+static inline void vc_set_color(struct vc_data *vc, unsigned char color)
+{
+ vc->vc_color = color_table[color & 0xF] |
+ (color_table[(color >> 4) & 0x7] << 4) |
+ (color & 0x80);
+ update_attr(vc);
+}
+#else
+static unsigned int printk_color[8];
+static inline void vc_set_color(const struct vc_data *vc, unsigned char c)
+{
+}
+#endif
+
/*
* Console on virtual terminal
*
* The console must be locked when we get here.
*/
-static void vt_console_print(struct console *co, const char *b, unsigned count)
+static void vt_console_print(struct console *co, const char *b, unsigned count,
+ unsigned int loglevel)
{
struct vc_data *vc = vc_cons[fg_console].d;
- unsigned char c;
+ unsigned char current_color, c;
static unsigned long printing;
const ushort *start;
ushort cnt = 0;
@@ -2385,11 +2414,19 @@
start = (ushort *)vc->vc_pos;
+ /*
+ * We always get a valid loglevel - <8> and "no level" is transformed
+ * to <4> in the typical kernel.
+ */
+ current_color = printk_color[loglevel];
+ vc_set_color(vc, current_color);
+
/* Contrived structure to try to emulate original need_wrap behaviour
* Problems caused when we have need_wrap set on '\n' character */
while (count--) {
c = *b++;
if (c == 10 || c == 13 || c == 8 || vc->vc_need_wrap) {
+ vc_set_color(vc, vc->vc_def_color);
if (cnt > 0) {
if (CON_IS_VISIBLE(vc))
vc->vc_sw->con_putcs(vc, start, cnt, vc->vc_y, vc->vc_x);
@@ -2402,6 +2439,7 @@
bs(vc);
start = (ushort *)vc->vc_pos;
myx = vc->vc_x;
+ vc_set_color(vc, current_color);
continue;
}
if (c != 13)
@@ -2409,6 +2447,7 @@
cr(vc);
start = (ushort *)vc->vc_pos;
myx = vc->vc_x;
+ vc_set_color(vc, current_color);
if (c == 10 || c == 13)
continue;
}
@@ -2430,6 +2469,7 @@
vc->vc_need_wrap = 1;
}
}
+ vc_set_color(vc, vc->vc_def_color);
set_cursor(vc);
quit:
diff -ruN linux-2.6.23.orig/drivers/net/netconsole.c
linux-2.6.23/drivers/net/netconsole.c
--- linux-2.6.23.orig/drivers/net/netconsole.c 2007-10-02
05:24:52.000000000 +0200
+++ linux-2.6.23/drivers/net/netconsole.c 2007-10-06 23:00:39.000000000 +0200
@@ -65,7 +65,8 @@
#define MAX_PRINT_CHUNK 1000
-static void write_msg(struct console *con, const char *msg, unsigned int len)
+static void write_msg(struct console *con, const char *msg, unsigned int len,
+ unsigned int loglevel)
{
int frag, left;
unsigned long flags;
diff -ruN linux-2.6.23.orig/drivers/serial/8250.c
linux-2.6.23/drivers/serial/8250.c
--- linux-2.6.23.orig/drivers/serial/8250.c 2007-10-02 05:24:52.000000000 +0200
+++ linux-2.6.23/drivers/serial/8250.c 2007-10-06 23:00:39.000000000 +0200
@@ -2464,7 +2464,8 @@
* The console_lock must be held when we get here.
*/
static void
-serial8250_console_write(struct console *co, const char *s, unsigned int count)
+serial8250_console_write(struct console *co, const char *s, unsigned int count,
+ unsigned int loglevel)
{
struct uart_8250_port *up = &serial8250_ports[co->index];
unsigned long flags;
diff -ruN linux-2.6.23.orig/drivers/serial/8250_early.c
linux-2.6.23/drivers/serial/8250_early.c
--- linux-2.6.23.orig/drivers/serial/8250_early.c 2007-10-02
05:24:52.000000000 +0200
+++ linux-2.6.23/drivers/serial/8250_early.c 2007-10-06 23:00:39.000000000 +0200
@@ -82,7 +82,8 @@
serial_out(port, UART_TX, c);
}
-static void __init early_serial8250_write(struct console *console,
const char *s, unsigned int count)
+static void __init early_serial8250_write(struct console *console,
+ const char *s, unsigned int count, unsigned int loglevel)
{
struct uart_port *port = &early_device.port;
unsigned int ier;
diff -ruN linux-2.6.23.orig/include/linux/console.h
linux-2.6.23/include/linux/console.h
--- linux-2.6.23.orig/include/linux/console.h 2007-10-02
05:24:52.000000000 +0200
+++ linux-2.6.23/include/linux/console.h 2007-10-06 23:00:39.000000000 +0200
@@ -93,7 +93,7 @@
struct console {
char name[16];
- void (*write)(struct console *, const char *, unsigned);
+ void (*write)(struct console *, const char *, unsigned, unsigned int);
int (*read)(struct console *, char *, unsigned);
struct tty_driver *(*device)(struct console *, int *);
void (*unblank)(void);
diff -ruN linux-2.6.23.orig/kernel/printk.c linux-2.6.23/kernel/printk.c
--- linux-2.6.23.orig/kernel/printk.c 2007-10-02 05:24:52.000000000 +0200
+++ linux-2.6.23/kernel/printk.c 2007-10-06 23:00:39.000000000 +0200
@@ -320,7 +320,8 @@
/*
* Call the console drivers on a range of log_buf
*/
-static void __call_console_drivers(unsigned long start, unsigned long end)
+static void __call_console_drivers(unsigned long start, unsigned long end,
+ unsigned int loglevel)
{
struct console *con;
@@ -328,7 +329,7 @@
if ((con->flags & CON_ENABLED) && con->write &&
(cpu_online(smp_processor_id()) ||
(con->flags & CON_ANYTIME)))
- con->write(con, &LOG_BUF(start), end - start);
+ con->write(con, &LOG_BUF(start), end - start, loglevel);
}
}
@@ -355,10 +356,11 @@
if ((start & LOG_BUF_MASK) > (end & LOG_BUF_MASK)) {
/* wrapped write */
__call_console_drivers(start & LOG_BUF_MASK,
- log_buf_len);
- __call_console_drivers(0, end & LOG_BUF_MASK);
+ log_buf_len, msg_log_level);
+ __call_console_drivers(0, end & LOG_BUF_MASK,
+ msg_log_level);
} else {
- __call_console_drivers(start, end);
+ __call_console_drivers(start, end, msg_log_level);
}
}
}
Jan Engelhardt wrote:
> On Oct 6 2007 15:53, Bill Davidsen wrote:
>> Jan Engelhardt wrote:
>>> 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.
>>>
>> I like it, although having a boot option would be nice (I have a friend with
>> color perception issues).
>
> 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
> vt.printk_color=1,1,1,1,5,3,2
>
>> I start my root xterm in white on blue for identification, so color coding
>> sounds like a great idea to me.
>
> 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 <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
On Oct 6 2007 20:50, Bill Davidsen wrote:
>>
>>> I start my root xterm in white on blue for identification, so color coding
>>> sounds like a great idea to me.
>>
>> 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?
A reparse did it.