[PATCH 1/2] Colored kernel output (run3)

[PATCH 1/2] Colored kernel output (run3)

[Jan Engelhardt]

Colored kernel message output (1/2)

This patch makes it possible to give kernel messages a selectable
color. It can be chosen at compile time, overridden at boot time,
and changed at run time.

References: http://lkml.org/lkml/2007/4/1/162
	http://lkml.org/lkml/2007/10/5/199

Signed-off-by: Jan Engelhardt <jengelh@gmx.de>

---
 drivers/char/Kconfig |   42 ++++++++++++++++++++++++++++++++++++++++++
 drivers/char/vt.c    |   23 +++++++++++++++++++++++
 2 files changed, 65 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,48 @@ config VT_CONSOLE
 
 	  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.
+
+	If unsure, say N.
+
+config VT_PRINTK_COLOR
+	hex "Colored kernel message output"
+	range 0x00 0xFF
+	depends on VT_CKO
+	default 0x07
+	---help---
+	This option defines with which color kernel messages will be
+	printed to the console.
+
+	The value you need to enter here is the value 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.
+
 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>
@@ -2344,6 +2345,23 @@ struct tty_driver *console_driver;
 
 #ifdef CONFIG_VT_CONSOLE
 
+static unsigned int printk_color __read_mostly = CONFIG_VT_PRINTK_COLOR;
+#ifdef CONFIG_VT_CKO
+module_param(printk_color, uint, 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 inline void vc_set_color(const struct vc_data *vc, unsigned char c)
+{
+}
+#endif
+
 /*
  *	Console on virtual terminal
  *
@@ -2384,12 +2402,14 @@ static void vt_console_print(struct cons
 		hide_cursor(vc);
 
 	start = (ushort *)vc->vc_pos;
+	vc_set_color(vc, printk_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 +2422,7 @@ static void vt_console_print(struct cons
 				bs(vc);
 				start = (ushort *)vc->vc_pos;
 				myx = vc->vc_x;
+				vc_set_color(vc, printk_color);
 				continue;
 			}
 			if (c != 13)
@@ -2409,6 +2430,7 @@ static void vt_console_print(struct cons
 			cr(vc);
 			start = (ushort *)vc->vc_pos;
 			myx = vc->vc_x;
+			vc_set_color(vc, printk_color);
 			if (c == 10 || c == 13)
 				continue;
 		}
@@ -2430,6 +2452,7 @@ static void vt_console_print(struct cons
 			vc->vc_need_wrap = 1;
 		}
 	}
+	vc_set_color(vc, vc->vc_def_color);
 	set_cursor(vc);
 
 quit:

Re: [PATCH 1/2] Colored kernel output (run3)

[Alan Cox]

On Sat, 6 Oct 2007 22:09:52 +0200 (CEST)
Jan Engelhardt <jengelh@computergmbh.de> wrote:

> 
> Colored kernel message output (1/2)
> 
> This patch makes it possible to give kernel messages a selectable
> color. It can be chosen at compile time, overridden at boot time,
> and changed at run time.

As the nearest thing to a tty maintainer I'd like to NAK this as "Silly"

Re: [PATCH 1/2] Colored kernel output (run3)

[Ingo Molnar]

* Jan Engelhardt <jengelh@computergmbh.de> wrote:

> Colored kernel message output (1/2)
> 
> This patch makes it possible to give kernel messages a selectable 
> color. It can be chosen at compile time, overridden at boot time, and 
> changed at run time.

minor fix: i had to use the slightly modified patch below instead of the 
one you posted, so that the second patch applies fine. Color output is 
just fine with this plus your #2 one applied. Adding 
vt.printk_color=0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08 to the boot line 
worked as expected.

	Ingo

--------------->
Colored kernel message output (1/2)

This patch makes it possible to give kernel messages a selectable
color. It can be chosen at compile time, overridden at boot time,
and changed at run time.

References: http://lkml.org/lkml/2007/4/1/162
	http://lkml.org/lkml/2007/10/5/199

Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 drivers/char/Kconfig |   42 ++++++++++++++++++++++++++++++++++++++++++
 drivers/char/vt.c    |   24 ++++++++++++++++++++++++
 2 files changed, 66 insertions(+)

Index: linux/drivers/char/Kconfig
===================================================================
--- linux.orig/drivers/char/Kconfig
+++ linux/drivers/char/Kconfig
@@ -58,6 +58,48 @@ config VT_CONSOLE
 
 	  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.
+
+	If unsure, say N.
+
+config VT_PRINTK_COLOR
+	hex "Colored kernel message output"
+	range 0x00 0xFF
+	depends on VT_CKO
+	default 0x07
+	---help---
+	This option defines with which color kernel messages will be
+	printed to the console.
+
+	The value you need to enter here is the value 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.
+
 config HW_CONSOLE
 	bool
 	depends on VT && !S390 && !UML
Index: linux/drivers/char/vt.c
===================================================================
--- linux.orig/drivers/char/vt.c
+++ linux/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>
@@ -2344,6 +2345,24 @@ struct tty_driver *console_driver;
 
 #ifdef CONFIG_VT_CONSOLE
 
+#ifdef CONFIG_VT_CKO
+static unsigned int printk_color __read_mostly = CONFIG_VT_PRINTK_COLOR;
+module_param(printk_color, uint, 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;
+static inline void vc_set_color(const struct vc_data *vc, unsigned char c)
+{
+}
+#endif
+
 /*
  *	Console on virtual terminal
  *
@@ -2384,12 +2403,14 @@ static void vt_console_print(struct cons
 		hide_cursor(vc);
 
 	start = (ushort *)vc->vc_pos;
+	vc_set_color(vc, printk_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 +2423,7 @@ static void vt_console_print(struct cons
 				bs(vc);
 				start = (ushort *)vc->vc_pos;
 				myx = vc->vc_x;
+				vc_set_color(vc, printk_color);
 				continue;
 			}
 			if (c != 13)
@@ -2409,6 +2431,7 @@ static void vt_console_print(struct cons
 			cr(vc);
 			start = (ushort *)vc->vc_pos;
 			myx = vc->vc_x;
+			vc_set_color(vc, printk_color);
 			if (c == 10 || c == 13)
 				continue;
 		}
@@ -2430,6 +2453,7 @@ static void vt_console_print(struct cons
 			vc->vc_need_wrap = 1;
 		}
 	}
+	vc_set_color(vc, vc->vc_def_color);
 	set_cursor(vc);
 
 quit:

Re: [PATCH 1/2] Colored kernel output (run3)

[Jan Engelhardt]

On Oct 7 2007 18:38, Ingo Molnar wrote:
>
>minor fix: i had to use the slightly modified patch below instead of the 
>one you posted, so that the second patch applies fine.

What is it that you changed? The printk patches are right at the front,
so there should not be any fuzz or offsets (might vary when
not at Linus's git top).

18:42 ichi:/ws/linux/linux-2.6.23 > head -n6 patches/series
checkpatch1.diff
checkpatch2.diff
checkfiles.diff
xt_TCPOPTSTRIP.diff
vt-printk-color.diff
vt-printk-color-per-loglevel.diff

>Color output is 
>just fine with this plus your #2 one applied. Adding 
>vt.printk_color=0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08 to the boot line 
>worked as expected.

Use decimal if feasible. (vt.printk_color=1,2,3,4,5,6,7,8)
The maximum command line still seems to be 255 on i386,
as I noticed while trying to replace the VGA color table :-(

Re: [PATCH 1/2] Colored kernel output (run3)

[Ingo Molnar]

Jan,

> This patch makes it possible to give kernel messages a selectable 
> color. It can be chosen at compile time, overridden at boot time, and 
> changed at run time.

here's some (good) text footprint data:

with the feature disabled (which is the default), the text size 
difference with patch #1:

  vmlinux:
     text    data     bss     dec     hex filename
  7732358 1157269  401408 9291035  8dc51b vmlinux.before
  7732358 1157269  401408 9291035  8dc51b vmlinux.after

i.e. no overhead. Text size difference with patch #2:

  vmlinux:
     text    data     bss     dec     hex filename
  7732358 1157269  401408 9291035  8dc51b vmlinux.before
  7732374 1157269  401408 9291051  8dc52b vmlinux.after

16 bytes, or 0.0002% of the total text size. So there's in essence no 
text overhead to talk about. So the text overhead argument is a red 
herring.

	Ingo

Re: [PATCH 1/2] Colored kernel output (run3)

[Jan Engelhardt]

On Oct 7 2007 18:44, Ingo Molnar wrote:
>> This patch makes it possible to give kernel messages a selectable 
>> color. It can be chosen at compile time, overridden at boot time, and 
>> changed at run time.
>
>here's some (good) text footprint data:
>
>with the feature disabled (which is the default), the text size 
>difference with patch #1:
>
>  vmlinux:
>     text    data     bss     dec     hex filename
>  7732358 1157269  401408 9291035  8dc51b vmlinux.before
>  7732358 1157269  401408 9291035  8dc51b vmlinux.after
>

I already posted the numbers. But it seems like the archives
like lkml.org or marc.info did not archive them (but i've cc'ed plenty
so you did not miss it.). See below.

>i.e. no overhead. Text size difference with patch #2:
>
>  vmlinux:
>     text    data     bss     dec     hex filename
>  7732358 1157269  401408 9291035  8dc51b vmlinux.before
>  7732374 1157269  401408 9291051  8dc52b vmlinux.after
>
>16 bytes, or 0.0002% of the total text size. So there's in essence no 
>text overhead to talk about. So the text overhead argument is a red 
>herring.

16 bytes, huh? Can't be. That would be like, perhaps 5, x86 instructions.

||Date: Sat, 6 Oct 2007 22:09:13 +0200 (CEST)
||Subject: [PATCH 0/2] Colored kernel output (run3)
||
||ok, so to make Oleg happy, here is run3 with a bool config option.
||
||i386>>
|| 48679  vt.o w/o anything
|| 48679  vt.o w/patch1
|| 49117  vt.o w/patch1        + CONFIG_VT_CKO=y
|| 49198  vt.o w/patch1+patch2 + CONFIG_VT_CKO=y
||--------
||   519  total cost of CKO
||
||x86_64>>
|| 71892  vt.o w/patch1+patch2
|| 72787  vt.o w/patch1+patch2 + CONFIG_VT_CKO=y
||--------
||   895

Re: [PATCH 1/2] Colored kernel output (run3)

[Ingo Molnar]

* Jan Engelhardt <jengelh@computergmbh.de> wrote:

> >  vmlinux:
> >     text    data     bss     dec     hex filename
> >  7732358 1157269  401408 9291035  8dc51b vmlinux.before
> >  7732374 1157269  401408 9291051  8dc52b vmlinux.after
> >
> >16 bytes, or 0.0002% of the total text size. So there's in essence no 
> >text overhead to talk about. So the text overhead argument is a red 
> >herring.
> 
> 16 bytes, huh? Can't be. That would be like, perhaps 5, x86 instructions.

yes, it's that low, and it's with the feature disabled. (People who 
enable a feature will of course see text size increase, but that's 
beside the point.)

	Ingo

Re: [PATCH 1/2] Colored kernel output (run3)

[Jan Engelhardt]

On Oct 7 2007 18:59, Ingo Molnar wrote:
>> >  vmlinux:
>> >     text    data     bss     dec     hex filename
>> >  7732358 1157269  401408 9291035  8dc51b vmlinux.before
>> >  7732374 1157269  401408 9291051  8dc52b vmlinux.after
>> >
>> >16 bytes, or 0.0002% of the total text size. So there's in essence no 
>> >text overhead to talk about. So the text overhead argument is a red 
>> >herring.
>> 
>> 16 bytes, huh? Can't be. That would be like, perhaps 5, x86 instructions.
>
>yes, it's that low, and it's with the feature disabled.

Ah, with CONFIG_CKO=n, right. But where does that 16 byte increase
come from, when vt.o itself remains constant in size?

Re: [PATCH 1/2] Colored kernel output (run3)

[Ingo Molnar]

* Jan Engelhardt <jengelh@computergmbh.de> wrote:

> 
> On Oct 7 2007 18:59, Ingo Molnar wrote:
> >> >  vmlinux:
> >> >     text    data     bss     dec     hex filename
> >> >  7732358 1157269  401408 9291035  8dc51b vmlinux.before
> >> >  7732374 1157269  401408 9291051  8dc52b vmlinux.after
> >> >
> >> >16 bytes, or 0.0002% of the total text size. So there's in essence no 
> >> >text overhead to talk about. So the text overhead argument is a red 
> >> >herring.
> >> 
> >> 16 bytes, huh? Can't be. That would be like, perhaps 5, x86 instructions.
> >
> >yes, it's that low, and it's with the feature disabled.
> 
> Ah, with CONFIG_CKO=n, right. But where does that 16 byte increase
> come from, when vt.o itself remains constant in size?

comes from printk.o:

   text    data     bss     dec     hex filename
   6068     231   17636   23935    5d7f kernel/printk.o
   6075     231   17636   23942    5d86 kernel/printk.o

the effect of the extra parameter. But that is not worth #ifdef-ing for. 
For all practical purposes there's no overhead.

	Ingo

Re: [PATCH 1/2] Colored kernel output (run3)

[Antonino A. Daplas]

On Sat, 2007-10-06 at 22:09 +0200, Jan Engelhardt wrote: 
> Colored kernel message output (1/2)
> 
> This patch makes it possible to give kernel messages a selectable
> color. It can be chosen at compile time, overridden at boot time,
> and changed at run time.
> 
> References: http://lkml.org/lkml/2007/4/1/162
> 	http://lkml.org/lkml/2007/10/5/199

This is quite a long thread :-)

> 
> Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
> 
> ---
>  drivers/char/Kconfig |   42 ++++++++++++++++++++++++++++++++++++++++++
>  drivers/char/vt.c    |   23 +++++++++++++++++++++++
>  2 files changed, 65 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,48 @@ config VT_CONSOLE
>  
>  	  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.
> +
> +	If unsure, say N.
> +
> +config VT_PRINTK_COLOR
> +	hex "Colored kernel message output"
> +	range 0x00 0xFF
> +	depends on VT_CKO
> +	default 0x07
> +	---help---
> +	This option defines with which color kernel messages will be
> +	printed to the console.
> +
> +	The value you need to enter here is the value is composed

The more correct term for "The value" is probably "The attribute".

> +	(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.)

You might have to include a warning that those values or attributes are 
interpreted differently depending on the driver used, and the above is
mostly true for 16-color console drivers only.

For 2-colors (we still have quite a few of them) only bit 0 is true for
color (0x00 and 0x01). The rest of the bits are interpreted as
attributes:

	0x02 - italic
	0x04 - underline
	0x08 - bold
	0x80 - blink

The italic, underline and bold attributes will show up in a 2-color
framebuffer console. The blink attribute is ignored.

With a 4-color fb console (4-level grayscale), those values are again
interpreted differently.

	0x00 - 0x00 : black
	0x01 - 0x06 : white
	0x07 - 0x08 : gray  
	the rest    : intense white

(If by mistake 0x0106 is used, it will produce a white on white display)

With an 8-color console, only the first 8 values are considered.

With a 16-color console, that is also not consistent:

With vgacon, it supports 16-color foreground (fg), 8-color
background (bg) at 256 chars. Becomes 8 fg and 8 bg with 512 chars.

With fbcon, it supports 16 fg and 16 bg at 256, 16 fg and 8 bg at
512 chars.

And for drivers that have their own con_build_attr() hook, they will be
interpreted differently again.

> +
> +	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.
> +

You may need to specify that the values here are the console default,
ie, the default_blue|grn|red boot options are not filled up.

>  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>
> @@ -2344,6 +2345,23 @@ struct tty_driver *console_driver;
>  
>  #ifdef CONFIG_VT_CONSOLE
>  
> +static unsigned int printk_color __read_mostly = CONFIG_VT_PRINTK_COLOR;
> +#ifdef CONFIG_VT_CKO
> +module_param(printk_color, uint, 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);

You may want to leave out the blink attribute (0x80) from this part.
Otherwise setterm -blink on|off will produce the opposite effect. 

Tony

Re: [PATCH 1/2] Colored kernel output (run3)

[Jan Engelhardt]

On Oct 9 2007 07:12, Antonino A. Daplas wrote:
>> 
>> References: http://lkml.org/lkml/2007/4/1/162
>> 	http://lkml.org/lkml/2007/10/5/199
>
>This is quite a long thread :-)

It was a patch series after all. But as Greg puts it, be persistent.

>> +config VT_PRINTK_COLOR
>> +	hex "Colored kernel message output"
>> +	range 0x00 0xFF
>> +	depends on VT_CKO
>> +	default 0x07
>> +	---help---
>> +	This option defines with which color kernel messages will be
>> +	printed to the console.
>> +
>> +	The value you need to enter here is the value is composed
>
>The more correct term for "The value" is probably "The attribute".

"The value for this kconfig entry" it should read in the minds.

>> +	(Foreground colors 0x08 to 0x0F do not work when a VGA
>> +	console font with 512 glyphs is used.)
>
>You might have to include a warning that those values or attributes are 
>interpreted differently depending on the driver used, and the above is
>mostly true for 16-color console drivers only.

Are there any other drivers besides vgacon and fbcon that use vt.c?

>For 2-colors [...] With a 4-color fb console (4-level grayscale) [...]
>With an 8-color console, only the first 8 values are considered.
>With a 16-color console, that is also not consistent:[...]

I see. That probably means the explanation of values moves from Kconfig 
to Documentation/. Somehow I think we could do without doc and let 
interested starts find out for themselves and learn a little about 
vgacon/fbcon. ;)

>With vgacon, it supports 16-color foreground (fg), 8-color
>background (bg) at 256 chars. Becomes 8 fg and 8 bg with 512 chars.
>
>With fbcon, it supports 16 fg and 16 bg at 256, 16 fg and 8 bg at
>512 chars.

And then there is fbiterm, which supports at least 16 fg/16 bg with ... 
the whole Unicode set of chars. :)

>And for drivers that have their own con_build_attr() hook, they will be
>interpreted differently again.

>> +	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.
>
>You may need to specify that the values here are the console default,
>ie, the default_blue|grn|red boot options are not filled up.

>> +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);
>
>You may want to leave out the blink attribute (0x80) from this part.
>Otherwise setterm -blink on|off will produce the opposite effect. 

But 0x80 might be interpreted in a different fashion for some othercon, 
yielding for example superbold rather than blinking.
I'll have to try this, because usually, setterm operates on TTYs
rather than VCs.

Re: [PATCH 1/2] Colored kernel output (run3)

[Antonino A. Daplas]

On Tue, 2007-10-09 at 01:31 +0200, Jan Engelhardt wrote:
> On Oct 9 2007 07:12, Antonino A. Daplas wrote:
> >> 
> >> References: http://lkml.org/lkml/2007/4/1/162
> >> 	http://lkml.org/lkml/2007/10/5/199
> >
> >This is quite a long thread :-)
> 
> It was a patch series after all. But as Greg puts it, be persistent.
> 
> >> +config VT_PRINTK_COLOR
> >> +	hex "Colored kernel message output"
> >> +	range 0x00 0xFF
> >> +	depends on VT_CKO
> >> +	default 0x07
> >> +	---help---
> >> +	This option defines with which color kernel messages will be
> >> +	printed to the console.
> >> +
> >> +	The value you need to enter here is the value is composed
> >
> >The more correct term for "The value" is probably "The attribute".
> 
> "The value for this kconfig entry" it should read in the minds.
> 
> >> +	(Foreground colors 0x08 to 0x0F do not work when a VGA
> >> +	console font with 512 glyphs is used.)
> >
> >You might have to include a warning that those values or attributes are 
> >interpreted differently depending on the driver used, and the above is
> >mostly true for 16-color console drivers only.
> 
> Are there any other drivers besides vgacon and fbcon that use vt.c?

All drivers under drivers/video/console. That would be:

vgacon
dummycon
fbcon
newport_con
sticon
promcon
mdacon

There are perhaps a few more drivers outside this directory, such as
sisusbcon or something.

<snip>

> >You may want to leave out the blink attribute (0x80) from this part.
> >Otherwise setterm -blink on|off will produce the opposite effect. 
> 
> But 0x80 might be interpreted in a different fashion for some othercon, 
> yielding for example superbold rather than blinking.

That's right. But setting the blink attribute is done with an XOR (^).
So 'setterm -blink' on will unset the blink attribute (0x80 ^ 0x80).

> I'll have to try this, because usually, setterm operates on TTYs
> rather than VCs.

Yes, but if the tty driver type is a virtual console, then vt.c is still
affected. 

Well the blink attribute is ignored by most drivers, if I'm not
mistaken. So you generally won't see the effect :-). But with fbcon, the
blink attribute is interpreted as "change background color from black to
light gray".

Tony

Re: [PATCH 1/2] Colored kernel output (run3)

[Bill Davidsen]

I tried something useful with this, see below.

Jan Engelhardt wrote:
> On Oct 9 2007 07:12, Antonino A. Daplas wrote:
>>> References: http://lkml.org/lkml/2007/4/1/162
>>> 	http://lkml.org/lkml/2007/10/5/199
>> This is quite a long thread :-)
> 
> It was a patch series after all. But as Greg puts it, be persistent.
> 
>>> +config VT_PRINTK_COLOR
>>> +	hex "Colored kernel message output"
>>> +	range 0x00 0xFF
>>> +	depends on VT_CKO
>>> +	default 0x07
>>> +	---help---
>>> +	This option defines with which color kernel messages will be
>>> +	printed to the console.
>>> +
>>> +	The value you need to enter here is the value is composed
>> The more correct term for "The value" is probably "The attribute".
> 
> "The value for this kconfig entry" it should read in the minds.
> 
>>> +	(Foreground colors 0x08 to 0x0F do not work when a VGA
>>> +	console font with 512 glyphs is used.)
>> You might have to include a warning that those values or attributes are 
>> interpreted differently depending on the driver used, and the above is
>> mostly true for 16-color console drivers only.
> 
> Are there any other drivers besides vgacon and fbcon that use vt.c?
> 
>> For 2-colors [...] With a 4-color fb console (4-level grayscale) [...]
>> With an 8-color console, only the first 8 values are considered.
>> With a 16-color console, that is also not consistent:[...]
> 
> I see. That probably means the explanation of values moves from Kconfig 
> to Documentation/. Somehow I think we could do without doc and let 
> interested starts find out for themselves and learn a little about 
> vgacon/fbcon. ;)

It probably means that the very clear explanations you shortened above 
should go it a file in Documentation. Particularly with the feature to 
have different levels of message different colors this allows monitoring 
of machines even when you can't read the message from a distance. When 
you see the magic color you can go look closer.
> 
>> With vgacon, it supports 16-color foreground (fg), 8-color
>> background (bg) at 256 chars. Becomes 8 fg and 8 bg with 512 chars.
>>
>> With fbcon, it supports 16 fg and 16 bg at 256, 16 fg and 8 bg at
>> 512 chars.
> 
> And then there is fbiterm, which supports at least 16 fg/16 bg with ... 
> the whole Unicode set of chars. :)
> 
>> And for drivers that have their own con_build_attr() hook, they will be
>> interpreted differently again.
> 
>>> +	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.
>> You may need to specify that the values here are the console default,
>> ie, the default_blue|grn|red boot options are not filled up.
> 
>>> +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);
>> You may want to leave out the blink attribute (0x80) from this part.
>> Otherwise setterm -blink on|off will produce the opposite effect. 
> 
> But 0x80 might be interpreted in a different fashion for some othercon, 
> yielding for example superbold rather than blinking.
> I'll have to try this, because usually, setterm operates on TTYs
> rather than VCs.

I tried something here, I have a monitor page on my window manager with 
lots of xterms opened to machines like DNS, HTTP, mail and NNTP servers. 
I use 100x25 xterms, with font size default. So just for fun I put a one 
line message on one in green on black (instead of black on white) and 
sized them all down to "unreadable" (cntl-right click menu) and I could 
clearly tell which one had the message even on the postage stamps.

Then I tried white on red, white on blue, and white on green. Those 
messages made the tiny xterm stand out as well. So I think it's a true 
statement that using colors to make important stuff stand out is 
something which in practice would be useful. Obviously if you use the 
"unreadable" font you can't read it, but that one xterm can be resized 
to a sane font to actually use it.

This isn't any dumber that Fedora printing the boot status of anything 
which fails in red, that may be "damned by faint praise" of course.

-- 
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

[PATCH 2/2] Colored kernel output (run3)

[Jan Engelhardt]

Colored kernel message output (2/2)

By popular request, this patch adds per-loglevel coloring.
The user may set values using vt.printk_color= or by modifying
the sysfs file in the running system.

Signed-off-by: Jan Engelhardt <jengelh@gmx.de>

---
 arch/x86_64/kernel/early_printk.c |   11 +++++++----
 drivers/char/Kconfig              |    4 +++-
 drivers/char/vt.c                 |   32 ++++++++++++++++++++++++--------
 drivers/net/netconsole.c          |    3 ++-
 drivers/serial/8250.c             |    3 ++-
 drivers/serial/8250_early.c       |    3 ++-
 include/linux/console.h           |    2 +-
 kernel/printk.c                   |   12 +++++++-----
 8 files changed, 48 insertions(+), 22 deletions(-)

Index: linux-2.6.23/arch/x86_64/kernel/early_printk.c
===================================================================
--- linux-2.6.23.orig/arch/x86_64/kernel/early_printk.c
+++ linux-2.6.23/arch/x86_64/kernel/early_printk.c
@@ -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 @@ static int early_serial_putc(unsigned ch
 	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 @@ static void __init simnow_init(char *str
 	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 @@ void early_printk(const char *fmt, ...)
 
 	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);
 }
 
Index: linux-2.6.23/drivers/char/Kconfig
===================================================================
--- linux-2.6.23.orig/drivers/char/Kconfig
+++ linux-2.6.23/drivers/char/Kconfig
@@ -75,7 +75,9 @@ config VT_PRINTK_COLOR
 	default 0x07
 	---help---
 	This option defines with which color kernel messages will be
-	printed to the console.
+	printed to the console. This applies to all log levels.
+	Colors for independent log levels can be set using the
+	vt.printk_color runtime option.
 
 	The value you need to enter here is the value is composed
 	(OR-ed) of a foreground and a background color.
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
@@ -2346,8 +2346,17 @@ struct tty_driver *console_driver;
 #ifdef CONFIG_VT_CONSOLE
 
 #ifdef CONFIG_VT_CKO
-static unsigned int printk_color __read_mostly = CONFIG_VT_PRINTK_COLOR;
-module_param(printk_color, uint, S_IRUGO | S_IWUSR);
+static unsigned int printk_color[8] __read_mostly = {
+	CONFIG_VT_PRINTK_COLOR, /* KERN_EMERG */
+	CONFIG_VT_PRINTK_COLOR, /* KERN_ALERT */
+	CONFIG_VT_PRINTK_COLOR, /* KERN_CRIT */
+	CONFIG_VT_PRINTK_COLOR, /* KERN_ERR */
+	CONFIG_VT_PRINTK_COLOR, /* KERN_WARNING */
+	CONFIG_VT_PRINTK_COLOR, /* KERN_NOTICE */
+	CONFIG_VT_PRINTK_COLOR, /* KERN_INFO */
+	CONFIG_VT_PRINTK_COLOR, /* KERN_DEBUG */
+};
+module_param_array(printk_color, uint, NULL, S_IRUGO | S_IWUSR);
 
 static void vc_set_color(struct vc_data *vc, unsigned char color)
 {
@@ -2357,7 +2366,7 @@ static void vc_set_color(struct vc_data 
 	update_attr(vc);
 }
 #else
-static unsigned int printk_color;
+static unsigned int printk_color[8];
 static inline void vc_set_color(const struct vc_data *vc, unsigned char c)
 {
 }
@@ -2369,10 +2378,11 @@ static inline void vc_set_color(const st
  * 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;
@@ -2403,7 +2413,13 @@ static void vt_console_print(struct cons
 		hide_cursor(vc);
 
 	start = (ushort *)vc->vc_pos;
-	vc_set_color(vc, printk_color);
+
+	/*
+	 * 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 */
@@ -2423,7 +2439,7 @@ static void vt_console_print(struct cons
 				bs(vc);
 				start = (ushort *)vc->vc_pos;
 				myx = vc->vc_x;
-				vc_set_color(vc, printk_color);
+				vc_set_color(vc, current_color);
 				continue;
 			}
 			if (c != 13)
@@ -2431,7 +2447,7 @@ static void vt_console_print(struct cons
 			cr(vc);
 			start = (ushort *)vc->vc_pos;
 			myx = vc->vc_x;
-			vc_set_color(vc, printk_color);
+			vc_set_color(vc, current_color);
 			if (c == 10 || c == 13)
 				continue;
 		}
Index: linux-2.6.23/drivers/net/netconsole.c
===================================================================
--- linux-2.6.23.orig/drivers/net/netconsole.c
+++ linux-2.6.23/drivers/net/netconsole.c
@@ -65,7 +65,8 @@ static int configured = 0;
 
 #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;
Index: linux-2.6.23/drivers/serial/8250.c
===================================================================
--- linux-2.6.23.orig/drivers/serial/8250.c
+++ linux-2.6.23/drivers/serial/8250.c
@@ -2464,7 +2464,8 @@ static void serial8250_console_putchar(s
  *	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;
Index: linux-2.6.23/drivers/serial/8250_early.c
===================================================================
--- linux-2.6.23.orig/drivers/serial/8250_early.c
+++ linux-2.6.23/drivers/serial/8250_early.c
@@ -82,7 +82,8 @@ static void __init putc(struct uart_port
 	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;
Index: linux-2.6.23/include/linux/console.h
===================================================================
--- linux-2.6.23.orig/include/linux/console.h
+++ linux-2.6.23/include/linux/console.h
@@ -93,7 +93,7 @@ void give_up_console(const struct consw 
 
 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);
Index: linux-2.6.23/kernel/printk.c
===================================================================
--- linux-2.6.23.orig/kernel/printk.c
+++ linux-2.6.23/kernel/printk.c
@@ -320,7 +320,8 @@ asmlinkage long sys_syslog(int type, cha
 /*
  * 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 @@ static void __call_console_drivers(unsig
 		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 @@ static void _call_console_drivers(unsign
 		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);
 		}
 	}
 }

Re: [PATCH 2/2] Colored kernel output (run3)

[Oleg Verych]

Thanks for dealing with my acidness in the first patch :)

But what about this one?

On Sat, Oct 06, 2007 at 10:10:01PM +0200, Jan Engelhardt wrote:
> 
> Colored kernel message output (2/2)
> 
> By popular request, this patch adds per-loglevel coloring.
> The user may set values using vt.printk_color= or by modifying
> the sysfs file in the running system.
> 
> Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
> 
> ---
>  arch/x86_64/kernel/early_printk.c |   11 +++++++----
>  drivers/char/Kconfig              |    4 +++-
>  drivers/char/vt.c                 |   32 ++++++++++++++++++++++++--------
>  drivers/net/netconsole.c          |    3 ++-
>  drivers/serial/8250.c             |    3 ++-
>  drivers/serial/8250_early.c       |    3 ++-
>  include/linux/console.h           |    2 +-
>  kernel/printk.c                   |   12 +++++++-----
>  8 files changed, 48 insertions(+), 22 deletions(-)

Making this amount changes and not thinking about more intelligent
coding of the functionality?

> Index: linux-2.6.23/arch/x86_64/kernel/early_printk.c
> ===================================================================
> --- linux-2.6.23.orig/arch/x86_64/kernel/early_printk.c
> +++ linux-2.6.23/arch/x86_64/kernel/early_printk.c
> @@ -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)
>  {

I mean, *write() have nothing to do with loglevels. If they do
(suddenly), then why not to use a char in the *str to make it possible? I
might be wrong, but there are already macros before format strings in
printk().

And this is not `loglevel' thing any more. It's attributes, which can be
used by many other drivers/file systems/schedulers/ what ever, if
developers, like Ingo, will extend printk() output to be more nice in
subsystems they develop.

So, maybe they can be extended, and functionality implemented in the
function bodies (which will be `do { } while (0)' if config is NO), but
*NOT* by passing additional argument to the functions.
___

Re: [PATCH 2/2] Colored kernel output (run3)

[Jan Engelhardt]

On Oct 6 2007 23:25, Oleg Verych wrote:
>> ---
>>  arch/x86_64/kernel/early_printk.c |   11 +++++++----
>>  drivers/char/Kconfig              |    4 +++-
>>  drivers/char/vt.c                 |   32 ++++++++++++++++++++++++--------
>>  drivers/net/netconsole.c          |    3 ++-
>>  drivers/serial/8250.c             |    3 ++-
>>  drivers/serial/8250_early.c       |    3 ++-
>>  include/linux/console.h           |    2 +-
>>  kernel/printk.c                   |   12 +++++++-----
>>  8 files changed, 48 insertions(+), 22 deletions(-)
>
>Making this amount changes and not thinking about more intelligent
>coding of the functionality?

Well humm.. in an unmodified kernel, the last function that has
knowledge of the loglevel is _call_console_drivers() in kernel/printk.c.
>From there, the call chain is directly -> __call_console_drivers() ->
drivers/char/vt.c:vt_console_print().

_call_console_drivers() skips the <N> substring and passes on the rest of the
message:

                if (msg_level < 0 && ((end - cur_index) > 2) &&
                                LOG_BUF(cur_index + 0) == '<' &&
                                LOG_BUF(cur_index + 1) >= '0' &&
                                LOG_BUF(cur_index + 1) <= '7' &&
                                LOG_BUF(cur_index + 2) == '>') {
                        msg_level = LOG_BUF(cur_index + 1) - '0';
                        cur_index += 3;
                        start_print = cur_index;
                }

>I mean, *write() have nothing to do with loglevels. If they do
>(suddenly), then why not to use a char in the *str to make it possible? I
>might be wrong, but there are already macros before format strings in
>printk().
>
>And this is not `loglevel' thing any more. It's attributes, which can be
>used by many other drivers/file systems/schedulers/ what ever, if
>developers, like Ingo, will extend printk() output to be more nice in
>subsystems they develop.

If I interpret you correctly, you want me to remove cur_index+=3
and instead reparse <N> in drivers/char/vt.c. But that's not good,
because if you use serial, we won't go to vt.c, and in the end,
8250.c would also need to parse <N>, which I think is just walking
around the hill.


kernel/printk.c -> 8250.c -> grab_loglevel_from_string -> ignore it and print
message
kernel/printk.c -> vt.c -> grab_loglevel_from_string -> print color according
to loglevel

VS

kernel/printk.c -> pass loglevel directly to 8250.c -> ignore loglevel and
print message
kernel/printk.c -> pass loglevel directly to vt.c -> print color according to
loglevel

Re: On text size and run time if config is "n", [PATCH 2/2] Colored kernel output (run3)

[Oleg Verych]

On Sat, Oct 06, 2007 at 11:27:54PM +0200, Jan Engelhardt wrote:
[]
> _call_console_drivers() skips the <N> substring and passes on the rest of the
> message:
> 
>                 if (msg_level < 0 && ((end - cur_index) > 2) &&
>                                 LOG_BUF(cur_index + 0) == '<' &&
>                                 LOG_BUF(cur_index + 1) >= '0' &&
>                                 LOG_BUF(cur_index + 1) <= '7' &&
>                                 LOG_BUF(cur_index + 2) == '>') {
>                         msg_level = LOG_BUF(cur_index + 1) - '0';
>                         cur_index += 3;
>                         start_print = cur_index;
>                 }
> 
> >I mean, *write() have nothing to do with loglevels. If they do
> >(suddenly), then why not to use a char in the *str to make it possible? I
> >might be wrong, but there are already macros before format strings in
> >printk().
> >
> >And this is not `loglevel' thing any more. It's attributes, which can be
> >used by many other drivers/file systems/schedulers/ what ever, if
> >developers, like Ingo, will extend printk() output to be more nice in
> >subsystems they develop.
> 
> If I interpret you correctly, you want me to remove cur_index+=3
> and instead reparse <N> in drivers/char/vt.c. But that's not good,
> because if you use serial, we won't go to vt.c, and in the end,
> 8250.c would also need to parse <N>, which I think is just walking
> around the hill.

I thought, i was talking about *write() functions, that got one
additional unrelated, non config removable API change in face of
`unsigned int loglevel'.

Idea. Extend those macro defines before format string with one
additional macro, that will be empty, if config is NO and having
colour byte otherwise.

In the *write() functions, have

 color = str[0];
 ++str;

in case if config is YES. And nothing otherwise.


Sorry, i don't know much about stuff, you've presented:

> kernel/printk.c -> 8250.c -> grab_loglevel_from_string -> ignore it and print
> message
> kernel/printk.c -> vt.c -> grab_loglevel_from_string -> print color according
> to loglevel

so maybe i just am an ignorant. Anyway this:

> VS
> 
> kernel/printk.c -> pass loglevel directly to 8250.c -> ignore loglevel and
> print message
> kernel/printk.c -> pass loglevel directly to vt.c -> print color according to
> loglevel

have no compile or run time optimization possible.
____

Re: On text size and run time if config is "n", [PATCH 2/2] Colored kernel output (run3)

[Jan Engelhardt]

On Oct 7 2007 00:28, Oleg Verych wrote:
>
>I thought, i was talking about *write() functions, that got one
>additional unrelated, non config removable API change in face of
>`unsigned int loglevel'.

Documentation/stable_api_nonsense.txt ;-)

>Idea. Extend those macro defines before format string with one
>additional macro, that will be empty, if config is NO and having
>colour byte otherwise.
>
>In the *write() functions, have
>
> color = str[0];
> ++str;

This is just as "bad" as the loglevel parameter. Because you'd have
to parse str[0] in _every_ write() function. Furthermore, the string
that is being printed also goes to klogd/syslog, including the <N>
tag already. If you now add a color byte in the KERN_* macros, then
that color byte would also go to syslog. Not good.

>Sorry, i don't know much about stuff, you've presented:

(Paraphrased one paragraph above.)