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

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

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

There is no way to disable this option. It would only add ugly
ifdefs, and the default color is the one that vt.c used for all the
past years anyway, so apart from the config option, nothing changes
for the conservative user.

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 |   33 +++++++++++++++++++++++++++++++++
 drivers/char/vt.c    |   17 +++++++++++++++++
 2 files changed, 50 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,39 @@ config VT_CONSOLE
 
 	  If unsure, say Y.
 
+config VT_PRINTK_COLOR
+	hex "Colored kernel message output"
+	range 0x00 0xFF
+	depends on VT_CONSOLE
+	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,17 @@ struct tty_driver *console_driver;
 
 #ifdef CONFIG_VT_CONSOLE
 
+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);
+}
+
 /*
  *	Console on virtual terminal
  *
@@ -2384,12 +2396,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 +2416,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 +2424,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 +2446,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 (run2)

[Denys Vlasenko]

On Saturday 06 October 2007 20:13, 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.

IMHO: useless bloat.

And yes, I've read entire thread. Sorry.
--
vda

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

[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                 |   30 +++++++++++++++++++++++-------
 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, 47 insertions(+), 21 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
@@ -65,7 +65,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
@@ -2345,8 +2345,17 @@ struct tty_driver *console_driver;
 
 #ifdef CONFIG_VT_CONSOLE
 
-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[] __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 inline void vc_set_color(struct vc_data *vc, unsigned char color)
 {
@@ -2362,10 +2371,11 @@ static inline void vc_set_color(struct v
  * 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;
@@ -2396,7 +2406,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 */
@@ -2416,7 +2432,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)
@@ -2424,7 +2440,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 0/2] Colored kernel output (run2)

[Oleg Verych]

On Sat, Oct 06, 2007 at 09:48:20PM +0200, Ingo Molnar wrote:
> > 
> > This is a "kernel messages color-l10n".
> > 
> > * text code size, that cannot be zero if config option is not set;
> 
> not really an issue. Changing the inline function to non-inline will get 
> rid of most of the text cost. Embedded wont build in a console.

I'm trying to say "text size *and* config option is not set". That
have nothing to do with other text size reductions.

> > * completely useless, if properly implemented in userspace (with much
> >   reacher functionality).
> 
> that's hogwash. No user-space runs during early bootup. (and yes i want 
> a color code at glance if something hangs in early bootup) Nothing will 
> color-code crashes, etc., etc. Control of the _kernel_ console by 
> user-space is complete nonsense.

If it is so important for major kernel developer like you, Ingo, then
why there's no scrollback at first place? Why nothing like that was
not implemented up until now?   

My first ever Linux hack was changing default console output color. I
think it was seven years ago. I though, it was not serious, if nobody
did that already (in the 2.2.14).

Please, don't mix important stuff here. I know, what kernel console is.

> The kernel console is one of the most important information channels of
> the kernel towards the user.

I'd say: towards hard OOPs-handling developer.

> this is nice and robust functionality that i personally welcome. The 
> default is not changed in any way.
> 
> (btw., i corrected the subject line to remove the 'NAK'. Why do you 
> think you can 'NAK' a patch in this field?)

I added comment (like this), so anyone can skip reading body, if headers
are "Oleg Verych && NAK". In case if `NAK' have a magic meaning in the
LKML, like control characters in the tty, i'm sorry.

But how to express opinion quickly and easily?
____

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

[Jan Engelhardt]

On Oct 6 2007 23:03, Oleg Verych wrote:
>> 
>> (btw., i corrected the subject line to remove the 'NAK'. Why do you 
>> think you can 'NAK' a patch in this field?)
>
>I added comment (like this), so anyone can skip reading body, if headers
>are "Oleg Verych && NAK". In case if `NAK' have a magic meaning in the
>LKML, like control characters in the tty, i'm sorry.
>
>But how to express opinion quickly and easily?

You can't. I think that people will usually be interested _why_ you
voted for or against something (given the number of vote-submitters
does not go through the roof). That clearly won't fit into the subject,
and even if RFC822 allowed it, it's only displayed like 40 chars wide.
The submitter (me in this case) will even look at *all* mails, so as to
(1) address the NAKs and (2) address the hidden feature requests in
ACKs.  :-)

About summary in the subject (Re: [PATCH 0/2] Colored kernel output (run2))

[Oleg Verych]

On Sat, Oct 06, 2007 at 11:03:38PM +0200, Jan Engelhardt wrote:
> 
> On Oct 6 2007 23:03, Oleg Verych wrote:
> >> 
> >> (btw., i corrected the subject line to remove the 'NAK'. Why do you 
> >> think you can 'NAK' a patch in this field?)
> >
> >I added comment (like this), so anyone can skip reading body, if headers
> >are "Oleg Verych && NAK". In case if `NAK' have a magic meaning in the
> >LKML, like control characters in the tty, i'm sorry.
> >
> >But how to express opinion quickly and easily?
> 
> You can't. I think that people will usually be interested _why_ you
> voted for or against something

Do you really think so? Yes, there are possibly LKML bots, that will
read all messages in every thread. But i doubt they are humans.

I also think, that kill-files and kill-names are common tools of the LKML
readers. Thus, if someone sees my name with something like NAK in the
subject, then nothing to worry about: next, please. I just amazed how
inefficiently Subject, To, Cc headers are used. Everybody hurry through
huge mail backlogs with subjects in thread all like one.

Summary and keywords headers are not used, so why not to make
greping/selecting interesting/useful messages more efficient (and not
only for those who is in Cc list)?

Every mail/news reader displays To and Subject, so latter is last hope of
increasing of efficiency, even in small threads.

> (given the number of vote-submitters does not go through the roof).
> That clearly won't fit into the subject,

Sorry, i cannot see, what you are trying to say here. To place all
acks-by to subject? No, just to get summary in one particular reply.

> and even if RFC822 allowed it, it's only displayed like 40 chars wide.
> The submitter (me in this case) will even look at *all* mails, so as to
> (1) address the NAKs and (2) address the hidden feature requests in
> ACKs.  :-)
____

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

[Ingo Molnar]

* Oleg Verych <olecom@flower.upol.cz> wrote:

> > > * completely useless, if properly implemented in userspace (with 
> > >   much reacher functionality).
> > 
> > that's hogwash. No user-space runs during early bootup. (and yes i 
> > want a color code at glance if something hangs in early bootup) 
> > Nothing will color-code crashes, etc., etc. Control of the _kernel_ 
> > console by user-space is complete nonsense.
> 
> If it is so important for major kernel developer like you, Ingo, then 
> why there's no scrollback at first place? Why nothing like that was 
> not implemented up until now?

even if it were true (which it isnt), that is not an argument against 
including a useful change that exists now and that people are interested 
in. (and yes, i have implemented kernel console improvements in the past 
and vga scrollback support was in fact amongst one of my first ever 
Linux kernel hacks so your comment is doubly wrong.)

> My first ever Linux hack was changing default console output color. I 
> think it was seven years ago. I though, it was not serious, if nobody 
> did that already (in the 2.2.14).
> 
> Please, don't mix important stuff here. I know, what kernel console 
> is.

your arguments are not an answer to my technical points, which i'll 
repeat here:

| | [...] No user-space runs during early bootup. (and yes i want a 
| | color code at glance if something hangs in early bootup) Nothing 
| | will color-code crashes, etc., etc. Control of the _kernel_ console 
| | by user-space is complete nonsense.

today's console code development goes in exactly the opposite direction: 
we are including (formerly-) user-space console functionality in the 
kernel so that we can for example print oopses even if we are in X mode.

> > this is nice and robust functionality that i personally welcome. The 
> > default is not changed in any way.
> > 
> > (btw., i corrected the subject line to remove the 'NAK'. Why do you 
> > think you can 'NAK' a patch in this field?)
> 
> I added comment (like this), so anyone can skip reading body, if 
> headers are "Oleg Verych && NAK". In case if `NAK' have a magic 
> meaning in the LKML, like control characters in the tty, i'm sorry.

yes, a 'NAK' has a particular meaning on lkml.

> But how to express opinion quickly and easily?

by writing a quick email expressing your opinion and waiting to see the 
discussion play out itself ...

but it is very rude to 'NAK' a patch and it should only be done 
carefully.

	Ingo

"Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

[Oleg Verych]

Hallo, Ingo.

On Sun, Oct 07, 2007 at 08:07:07AM +0200, Ingo Molnar wrote:
> 
> * Oleg Verych <olecom@flower.upol.cz> wrote:
> 
> > > > * completely useless, if properly implemented in userspace (with 
> > > >   much reacher functionality).
> > > 
> > > that's hogwash. No user-space runs during early bootup. (and yes i 
> > > want a color code at glance if something hangs in early bootup) 
> > > Nothing will color-code crashes, etc., etc. Control of the _kernel_ 
> > > console by user-space is complete nonsense.
> > 
> > If it is so important for major kernel developer like you, Ingo, then 
> > why there's no scrollback at first place? Why nothing like that was 
> > not implemented up until now?

To clarify. `Scrollback' here is *useful* scrollback during early boot
and OOPs (which is absent, AFAIK), "nothing like that" is coloring of the
messages by loglevel.

> even if it were true (which it isnt), that is not an argument against 
> including a useful change that exists now and that people are interested 
> in.

Coloring isn't useful. If it was, it would be implemented ~16 years ago.

> (and yes, i have implemented kernel console improvements in the past 
> and vga scrollback support was in fact amongst one of my first ever 
> Linux kernel hacks so your comment is doubly wrong.)

This `scrollback' is usual late boot / console one. If fact useful,
until first tty switch or if `screen` cannot be used. But for some
reason if scrolling region (DECSTBM) is less than whole screen, nothing
works. And if width set to odd number of columns

`stty columns $((80-1))`

whole output becomes somewhat funny.

> > My first ever Linux hack was changing default console output color. I 
> > think it was seven years ago. I though, it was not serious, if nobody 
> > did that already (in the 2.2.14).
> > 
> > Please, don't mix important stuff here. I know, what kernel console 
> > is.
> 
> your arguments are not an answer to my technical points, which i'll 
> repeat here:
> 
> | | [...] No user-space runs during early bootup. (and yes i want a 
> | | color code at glance if something hangs in early bootup)

The kernel developer talks about what is important to him. This is not
technical point.

> | | Nothing will color-code crashes, etc., etc.

Because without userspace kernel panics. And if something is broken very
early, then time to do kernel development better (not to break working
early booting stuff for everybody), rather than to talk about importance
of the color. I think, same applies to kernel debugger, that still
is not in mainline (AFAIK).

> | | Control of the _kernel_ console by user-space is complete nonsense.

Not control, but flexible coloring (any kind of highlighting), selecting
of useful information, i.e. making output more user friendly. This are
things, which all *users* (not developers) expect in boot process of the
one's _machine_, as opposed to debugging (early boot) kernel bugs.

> today's console code development goes in exactly the opposite direction: 
> we are including (formerly-) user-space console functionality in the 
> kernel so that we can for example print oopses even if we are in X mode.

I'm not sure what kind of printing it is. I do not use X much, but when i
did, i recall MCE messages in xterm, when over-clocked CPU was going
crazy, though.

> > > this is nice and robust functionality that i personally welcome. The 
> > > default is not changed in any way.
> > > 
> > > (btw., i corrected the subject line to remove the 'NAK'. Why do you 
> > > think you can 'NAK' a patch in this field?)
> > 
> > I added comment (like this), so anyone can skip reading body, if 
> > headers are "Oleg Verych && NAK". In case if `NAK' have a magic 
> > meaning in the LKML, like control characters in the tty, i'm sorry.
> 
> yes, a 'NAK' has a particular meaning on lkml.

But what about (NAK && ! any_important_kernel_developer_name)?

> > But how to express opinion quickly and easily?
> 
> by writing a quick email expressing your opinion and waiting to see the 
> discussion play out itself ...

Quick is not for me (i did accepted "config NO" size reduction review,
btw), but for those, who reads LKML or looks on archive search results.

I just am amazed how `Subject' is miss-used. I personally like to have
most of the interesting information gathered from all that thousands of
(not only LKML) messages. But a thread with all-like-one subjects,
subjects that for some reason are taking place on the screen of
MUAs (empty space if they are the same). Thus, short (easy to get right)
summary in subject is more that welcome by me.

> but it is very rude to 'NAK' a patch and it should only be done 
> carefully.

That was a review of the implementation, an opinion on whole idea. Idea
of yet another ugly kernel functionality, just because *BSD kernels have
one.

I like highlighting, i like to make it very flexible, nice and
interesting[0]. This is possible only in the userspace, right after first
process ran from initramfs. This happens very quickly usually. And yes,
this is not acceptable/available for kernel developers/maintainers.

[0] not much, but something <ftp://flower.upol.cz/upload/debian.sh> 

> 	Ingo
____

NAK nettiquete (was Re: "Re: [PATCH 0/2] Colored kernel output (run2)"

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]

On Sun, 07 Oct 2007 13:10:35 +0200, Oleg Verych said:

> > > I added comment (like this), so anyone can skip reading body, if 
> > > headers are "Oleg Verych && NAK". In case if `NAK' have a magic 
> > > meaning in the LKML, like control characters in the tty, i'm sorry.
> > 
> > yes, a 'NAK' has a particular meaning on lkml.
> 
> But what about (NAK && ! any_important_kernel_developer_name)?

The few times I've tried to NAK something outright, I've always tried to attach
plenty of technical explanation (usually of the form "Gaak, this oopses my
laptop") :), and cc: the relevant important_name, and hope they listen.

Fortunately, most of the time I can get away with a politely phrased variation of
"important_name would probably appreciate if you fixed XYZ and resubmitted"
comment.. ;)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: NAK nettiquete (was Re: "Re: [PATCH 0/2] Colored kernel output (run2)"

[Alan Cox]

> The few times I've tried to NAK something outright, I've always tried to attach
> plenty of technical explanation 

Fair comment to my "silly" response

The problems I see are

- We run on a lot more than VGA PC consoles
- We have serial consoles (which may or may not be VT132/ANSI compliant)
- The printk paths are run at IRQ time ASAP to get messages to console,
that could mean we split existing colour escape code processing and the
like.
- People redirect the console feed other places via ioctl. Some of them
parse "<%d>" as the start

But most importantly:

- If you want to do "pretty" boot up you do it in X or frame buffer
(which is going to get easier and easier with the X shift to kernel side
video support)
- If you want to do a coloured display after boot then this is a matter
for your logging tools

As with translation the kernel is the wrong place to do this work.

What I would much rather people thought about was

- Marker modes for translation (so you know which bits of a message are
formatted up)
- More consistency on the use of "name: blah" to make it easier to parse
- Turning more messages from kernel logs to events when it makes sense
(eg "Disk Full", "Media Error", "CPU on fire")

So if you want to do a pretty boot, then solve the big picture, the
framebuffer initrd graphical boot, the boot display, the combining of
artwork and messages in user space from initrd run code.

'leet kernel messages in flashing red are not really the problem that
needs solving to do this.

Alan

Re: NAK nettiquete (was Re: "Re: [PATCH 0/2] Colored kernel output (run2)"

[Jan Engelhardt]

On Oct 7 2007 16:12, Alan Cox wrote:
>
>- We run on a lot more than VGA PC consoles
>- We have serial consoles (which may or may not be VT132/ANSI compliant)

Yes, and the serial driver does not usually pass on vc->vc_color to the real
hardware. If it did, it would have to transform it back into an unportable
ANSI code and send that. So we don't do that.

>- The printk paths are run at IRQ time ASAP to get messages to console,
>that could mean we split existing colour escape code processing and the
>like.

Oleg already persuaded me to add options to toally configure it out,
so there is no impact for you.

>- People redirect the console feed other places via ioctl. Some of them
>parse "<%d>" as the start

Interestingly enough, the <n> part is not transferred over serial,
but that seems another story.

>- If you want to do "pretty" boot up you do it in X or frame buffer
>(which is going to get easier and easier with the X shift to kernel side
>video support)

fb is slow. Feels like a 9600bps serial line.

Let everyone have his own fun.

Re: NAK nettiquete (was Re: "Re: [PATCH 0/2] Colored kernel output (run2)"

[Alan Cox]

> >- If you want to do "pretty" boot up you do it in X or frame buffer
> >(which is going to get easier and easier with the X shift to kernel side
> >video support)
> 
> fb is slow. Feels like a 9600bps serial line.

So fix your fb. There is enough information to cover 2D scrolling for
most modern cards now.

> Let everyone have his own fun.

The point isn't to put everyones "fun" into the kernel, or by now it
would have become a steaming heap.

Re: NAK nettiquete (was Re: "Re: [PATCH 0/2] Colored kernel output (run2)"

[Jan Engelhardt]

On Oct 7 2007 17:23, Alan Cox wrote:
>
>>>- If you want to do "pretty" boot up you do it in X or frame buffer
>>>(which is going to get easier and easier with the X shift to kernel side
>>>video support)
>> 
>> fb is slow. Feels like a 9600bps serial line.
>
>So fix your fb. There is enough information to cover 2D scrolling for
>most modern cards now.
>
>> Let everyone have his own fun.
>
>The point isn't to put everyones "fun" into the kernel, or by now it
>would have become a steaming heap.

We do have a steaming heap of obscure hardware drivers, actually.

Re: "Re: [PATCH 0/2] Colored kernel output (run2)"

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1059 bytes --]

(changing Subject: back again, since Alan's returning to that topic...)

On Sun, 07 Oct 2007 16:12:22 BST, Alan Cox said:

> What I would much rather people thought about was
> 
> - Marker modes for translation (so you know which bits of a message are
> formatted up)
> - More consistency on the use of "name: blah" to make it easier to parse
> - Turning more messages from kernel logs to events when it makes sense
> (eg "Disk Full", "Media Error", "CPU on fire")

What would it take to have a pointer chain at a *well known* location or
similar magic so if a machine died, I'd be able to hook up a laptop with a
FireWire cable and do firescope magic to extract at least/just the dmesg buffer?  

(Yes, I know this requires a 1394 port and some previous cooperation and setup
on the part of the 1394 driver. Assume I can get away with saying "add this
to your kernel command line to make debugging easier for me" ;)

(And yes, 5 years ago I'd have been wanting a "dump dmesg to floppy" patch,
but times move one and 1394 is more likely than a floppy now...)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: NAK nettiquete (was Re: "Re: [PATCH 0/2] Colored kernel output (run2)"

[Arnaldo Carvalho de Melo]

Em Sun, Oct 07, 2007 at 04:12:22PM +0100, Alan Cox escreveu:
> > The few times I've tried to NAK something outright, I've always tried to attach
> > plenty of technical explanation 
> 
> Fair comment to my "silly" response
> 
> The problems I see are
> 
> - We run on a lot more than VGA PC consoles
> - We have serial consoles (which may or may not be VT132/ANSI compliant)
> - The printk paths are run at IRQ time ASAP to get messages to console,
> that could mean we split existing colour escape code processing and the
> like.
> - People redirect the console feed other places via ioctl. Some of them
> parse "<%d>" as the start
> 
> But most importantly:
> 
> - If you want to do "pretty" boot up you do it in X or frame buffer
> (which is going to get easier and easier with the X shift to kernel side
> video support)
> - If you want to do a coloured display after boot then this is a matter
> for your logging tools
> 
> As with translation the kernel is the wrong place to do this work.
> 
> What I would much rather people thought about was
> 
> - Marker modes for translation (so you know which bits of a message are
> formatted up)
> - More consistency on the use of "name: blah" to make it easier to parse
> - Turning more messages from kernel logs to events when it makes sense
> (eg "Disk Full", "Media Error", "CPU on fire")
> 
> So if you want to do a pretty boot, then solve the big picture, the
> framebuffer initrd graphical boot, the boot display, the combining of
> artwork and messages in user space from initrd run code.
> 
> 'leet kernel messages in flashing red are not really the problem that
> needs solving to do this.

Its kinda like we pronounce printk dead for first level error reporting.
We are getting more and more closer to that with all the macros that do
just that... I'm not following kernel development as I think I should
be, but...:

dev_printk
dev_dbg
dev_vdbg
DCCP_WARN
DCCP_CRIT
DCCP_PR_DEBUG
LIMIT_NETDEBUG

With some more researching I'm sure I'd find more printk wrappers. But I
guess this should make some sort of point: using these wrappers get us
closer to what Alan wants: consistent printk messages. Such that the
life of kcolorls like wrappers get to the point that the life of user
level debugging loggers can jump and shout in happiness for providing
even nifty popup messages on "modern desktops".

As if the problem with modern desktops (or server consoles) was just
that... gimme a way to configure wpa-psk on my brand new company
notebook without having to resort to, ugh, command line assistance...
Bluetooth without having to manually do "service bluetooth start"...

- Arnaldo

P.S.: I know that that is just in the making, dbus and a lot of other
buzzwords that keep promising to solve these kinds of problems :-)

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

[Ingo Molnar]

* Oleg Verych <olecom@flower.upol.cz> wrote:

> > even if it were true (which it isnt), that is not an argument 
> > against including a useful change that exists now and that people 
> > are interested in.
> 
> Coloring isn't useful. If it was, it would be implemented ~16 years
> ago.

Congratulations, this is the most stupid argument i've ever read on 
lkml.

	Ingo

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

[Rene Herman]

On 10/07/2007 06:12 PM, Ingo Molnar wrote:

> * Oleg Verych <olecom@flower.upol.cz> wrote:

>> Coloring isn't useful. If it was, it would be implemented ~16 years
>> ago.
> 
> Congratulations, this is the most stupid argument i've ever read on 
> lkml.

"Ay. World is finished. Everyone can go home and watch Friends reruns now."

But well, there actually have been worse arguments given that VGA console is 
getting less and less important. I recently did a perusal of alternative 
distributions and didn't find a single one that didn't default to having a 
splash screen hide the kernel during boot (and if I'm not mistaken, only one 
of them provided me with the option during installation to not boot into X 
immediately afterwards).

Sure, that in itself needn't necesarily be of concern to anyone who, err, is 
not concerned but any such colouring feature appearing when there's only a 
smathering of people left that still cares about the VGA console in the 
first place really isn't all _that_ far out as an argument...

Rene.

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

[Jan Engelhardt]

On Oct 7 2007 20:47, Rene Herman wrote:
>
>> > Coloring isn't useful. If it was, it would be implemented ~16 years
>> > ago.
>> 
>> Congratulations, this is the most stupid argument i've ever read on lkml.
>
> "Ay. World is finished. Everyone can go home and watch Friends reruns now."
>
> But well, there actually have been worse arguments given that VGA console is
> getting less and less important.
>[...]
> Sure, that in itself needn't necesarily be of concern to anyone who, err, is
> not concerned but any such colouring feature appearing when there's only a
> smathering of people left that still cares about the VGA console in the first
> place really isn't all _that_ far out as an argument...

In case you have not noticed, the coloring also applies to FB.
As far as I can oversee, it's only "missing" for serial and PROMs.

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

[Rene Herman]

On 10/07/2007 08:58 PM, Jan Engelhardt wrote:

> On Oct 7 2007 20:47, Rene Herman wrote:

>>>> Coloring isn't useful. If it was, it would be implemented ~16 years
>>>> ago.
>>> Congratulations, this is the most stupid argument i've ever read on lkml.
>> "Ay. World is finished. Everyone can go home and watch Friends reruns now."
>>
>> But well, there actually have been worse arguments given that VGA console is
>> getting less and less important.
>> [...]
>> Sure, that in itself needn't necesarily be of concern to anyone who,
>> err, is not concerned but any such colouring feature appearing when
>> there's only a smathering of people left that still cares about the VGA
>> console in the first place really isn't all _that_ far out as an
>> argument...
> 
> In case you have not noticed, the coloring also applies to FB. As far as
> I can oversee, it's only "missing" for serial and PROMs.

Must say I did concentrate on VGA, but the [...] bit in the quote above was 
about how everything I encountered put up a bootsplash hiding _everything_ 
and about booting into X immediately, not about FB...

I saw you remark on FB console in a reply to Alan just now and I quite agree 
with you. The (current) FB console is slow and I'll add "dumb" myself. When 
you have a 1280x1024 screen available, you get to do cool things like put up 
nice little windows and exclamation mark icons on errors, not just pretend 
you're really 132x50 (or whatever).

Alan's sketched more generic markup/unification would be The Way Forward it 
seems. Given that TWF is mostly defined as "That Which Is Not" (and how it 
seems to have a tendency to defend that status vigorously) telling me/us to 
shelve that objection for 10 years might be okay -- but generally I'm having 
a fairly hard time getting excited about printk colourizing.

Rene.

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

[Jan Engelhardt]

On Oct 7 2007 21:27, Rene Herman wrote:
>
> I saw you remark on FB console in a reply to Alan just now and I
> quite agree with you. The (current) FB console is slow and I'll add
> "dumb" myself. When you have a 1280x1024 screen available, you get
> to do cool things like put up nice little windows and exclamation
> mark icons on errors, not just pretend you're really 132x50 (or
> whatever).

CVIDIX, while card-dependent I think, is much better at speed than FB
while still providing 720x400 or even higher.

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

[Willy Tarreau]

On Sun, Oct 07, 2007 at 08:47:52PM +0200, Rene Herman wrote:
> On 10/07/2007 06:12 PM, Ingo Molnar wrote:
> 
> >* Oleg Verych <olecom@flower.upol.cz> wrote:
> 
> >>Coloring isn't useful. If it was, it would be implemented ~16 years
> >>ago.
> >
> >Congratulations, this is the most stupid argument i've ever read on 
> >lkml.
> 
> "Ay. World is finished. Everyone can go home and watch Friends reruns now."
> 
> But well, there actually have been worse arguments given that VGA console 
> is getting less and less important. I recently did a perusal of alternative 
> distributions and didn't find a single one that didn't default to having a 
> splash screen hide the kernel during boot (and if I'm not mistaken, only 
> one of them provided me with the option during installation to not boot 
> into X immediately afterwards).

I don't recall having seen any splash screen on Slackware. And fortunately,
the mainstream distros still provide the option to boot in text mode.

> Sure, that in itself needn't necesarily be of concern to anyone who, err, 
> is not concerned but any such colouring feature appearing when there's only 
> a smathering of people left that still cares about the VGA console in the 
> first place really isn't all _that_ far out as an argument...

There are two distinct populations :
  - those who are afraid of boot messages and prefer "splash" screens.
    Those people are most common users, grown in non-IT environments. They
    are happy to see a big logo on their BIOS to hide important boot errors,
    and they are the ones who would never have imagined that pressing Escape
    during the boot of windows 3.1/95 provided them with the full text
    messages. Basically, they want to ensure they will never have to worry
    about things they don't understand.

  - those who are troubleshooting their system in the early stages (kernel,
    filesystems, network, services, ...). These ones *need* boot messages.
    And there, depending on the hardware, sometimes the FB is better because
    it shows larger lines, sometimes it's worse because the scrollback is
    limited by too low memory.

I personally fit in the second category. And I'm sure most people on this
list do. I would be miserably sad if I couldn't get my boot messages
anymore. It already irritates me a lot to loose the ones displayed before
switching to frame-buffer when a hang happens just afterwards...

I would say that while I'm not particularly fond of flashy colors
everywhere, I think that being able to use colors to indicate particular
actions in progress or conditions can be a good thing. RAID errors,
devices disabled due to command-line parameters, and general anomalies
which can cause a hang or panic a few line laters are worth coloring.
And I don't believe in userland's help here, because for that type of
messages, the indication should be returned immediately. For instance,
anyone who has experienced read errors on and IDE disk knows that it
can literally take hours/days to boot, after displaying thousands of
messages. Here, having the ability to see that no IRQ was assigned or
something like this could help.

Regards,
Willy

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

[Oleg Verych]

On Sun, Oct 07, 2007 at 09:13:09PM +0200, Willy Tarreau wrote:
> On Sun, Oct 07, 2007 at 08:47:52PM +0200, Rene Herman wrote:
> > On 10/07/2007 06:12 PM, Ingo Molnar wrote:
> > 
> > >* Oleg Verych <olecom@flower.upol.cz> wrote:
> > 
> > >>Coloring isn't useful. If it was, it would be implemented ~16 years
> > >>ago.
> > >
> > >Congratulations, this is the most stupid argument i've ever read on 
> > >lkml.
[]
> I would say that while I'm not particularly fond of flashy colors
> everywhere, I think that being able to use colors to indicate particular
> actions in progress or conditions can be a good thing. RAID errors,
> devices disabled due to command-line parameters, and general anomalies
> which can cause a hang or panic a few line laters are worth coloring.

That *is* the coloring, i'm talking about.

> And I don't believe in userland's help here, because for that type of
> messages, the indication should be returned immediately.

In the very buggy cases, i think, everything just hang. Otherwise
initramfs stuff can deal with it.

> For instance, anyone who has experienced read errors on and IDE disk
> knows that it can literally take hours/days to boot, after displaying
> thousands of messages. Here, having the ability to see that no IRQ was
> assigned or something like this could help.

As i'm pretty much in all that text(tty)-mode stuff anyway, maybe after
some time i will propose something klibc/tty based. Mainly a bit of user
interface: split scrolling regions for errors and notifications; flexible
color schemas (keyword highlighting); keyboard events. Of course it will
work in such IDE cases, only if driver is a module.
____

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

[Ingo Molnar]

* Oleg Verych <olecom@flower.upol.cz> wrote:

> > For instance, anyone who has experienced read errors on and IDE disk 
> > knows that it can literally take hours/days to boot, after 
> > displaying thousands of messages. Here, having the ability to see 
> > that no IRQ was assigned or something like this could help.
> 
> As i'm pretty much in all that text(tty)-mode stuff anyway, maybe 
> after some time i will propose something klibc/tty based. Mainly a bit 
> of user interface: split scrolling regions for errors and 
> notifications; flexible color schemas (keyword highlighting); keyboard 
> events. Of course it will work in such IDE cases, only if driver is a 
> module.

Jan's code is here today and it works fine for me. How can you 
coherently argue against the plain fact that his feature solves my 
usecases perfectly fine, while your hypothetical solution clearly does 
not solve them? (Although i'm not too hopeful you'll give me a straight 
answer to my straight question, given your track record on lkml. It is 
almost as if you were more interested in ranting and in controversy than 
in the progress of Linux.)

	Ingo

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

[Alan Cox]

> Jan's code is here today and it works fine for me. How can you 
> coherently argue against the plain fact that his feature solves my 
> usecases perfectly fine,

So add a notifier for console printk output. Then you can keep whatever
out of kernel patches you like for printk output in chinese, colour,
swedish chef ...

And of those the chinese is probably a good deal more relevant than the
colour.

Alan

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

[Bill Davidsen]

Alan Cox wrote:
>> Jan's code is here today and it works fine for me. How can you 
>> coherently argue against the plain fact that his feature solves my 
>> usecases perfectly fine,
> 
> So add a notifier for console printk output. Then you can keep whatever
> out of kernel patches you like for printk output in chinese, colour,
> swedish chef ...
> 
> And of those the chinese is probably a good deal more relevant than the
> colour.
> 
If kernel printing were going to be done over, I would suggest that 
instead of the current fixed format strings, the format argument would 
be an index, an ordinal into an array of *char pointers, and the string 
so described would be used as the format. These strings and pointers 
could be put in two modules, one part of init to be released after boot 
like other init code, one resident. And by loading different modules the 
error messages could be as short, long, or colorful as desired, and in 
any language and/or character set available via escape sequence.

Of course people would say it's larger than what we have, harder to use, 
would take a huge effort to convert existing messages... and that's all 
true. But as you said, the Chinese is probably more germane than colors. 
Think about it, kernel messages in Gaelic or even rap lyrics
   "Hate to tell you,
    it must be said,
    I can't boot
    your disk be dead."
Or Latin, CRDOS had some comments in Latin and one PhD who thought his 
code was best described in BNF.

To be serious, a notifier to a user program, *after boot*, would allow 
all this flexibility, although I still think it's too late to change.

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

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

[Willy Tarreau]

On Sun, Oct 07, 2007 at 09:47:25PM +0200, Oleg Verych wrote:
> On Sun, Oct 07, 2007 at 09:13:09PM +0200, Willy Tarreau wrote:
> > On Sun, Oct 07, 2007 at 08:47:52PM +0200, Rene Herman wrote:
> > > On 10/07/2007 06:12 PM, Ingo Molnar wrote:
> > > 
> > > >* Oleg Verych <olecom@flower.upol.cz> wrote:
> > > 
> > > >>Coloring isn't useful. If it was, it would be implemented ~16 years
> > > >>ago.
> > > >
> > > >Congratulations, this is the most stupid argument i've ever read on 
> > > >lkml.
> []
> > I would say that while I'm not particularly fond of flashy colors
> > everywhere, I think that being able to use colors to indicate particular
> > actions in progress or conditions can be a good thing. RAID errors,
> > devices disabled due to command-line parameters, and general anomalies
> > which can cause a hang or panic a few line laters are worth coloring.
> 
> That *is* the coloring, i'm talking about.
> 
> > And I don't believe in userland's help here, because for that type of
> > messages, the indication should be returned immediately.
> 
> In the very buggy cases, i think, everything just hang. Otherwise
> initramfs stuff can deal with it.
> 
> > For instance, anyone who has experienced read errors on and IDE disk
> > knows that it can literally take hours/days to boot, after displaying
> > thousands of messages. Here, having the ability to see that no IRQ was
> > assigned or something like this could help.
> 
> As i'm pretty much in all that text(tty)-mode stuff anyway, maybe after
> some time i will propose something klibc/tty based. Mainly a bit of user
> interface: split scrolling regions for errors and notifications; flexible
> color schemas (keyword highlighting); keyboard events. Of course it will
> work in such IDE cases, only if driver is a module.

But what I cannot understand is how you expect userspace to work while
the lines are being displayed. If this is just to repaint the screen
once everything is up, it is 100% useless. I'm interested in seeing
errors _while_ they are happening. Basically, I need no color if the
machine boots correctly.

Willy

initramfs: coloring in userspace, "[PATCH 0/2] Colored kernel output (run2)"

[Oleg Verych]

On Mon, Oct 08, 2007 at 05:23:05AM +0200, Willy Tarreau wrote:
> On Sun, Oct 07, 2007 at 09:47:25PM +0200, Oleg Verych wrote:
> > > For instance, anyone who has experienced read errors on and IDE disk
> > > knows that it can literally take hours/days to boot, after displaying
> > > thousands of messages. Here, having the ability to see that no IRQ was
> > > assigned or something like this could help.
> > 
> > As i'm pretty much in all that text(tty)-mode stuff anyway, maybe after
> > some time i will propose something klibc/tty based. Mainly a bit of user
> > interface: split scrolling regions for errors and notifications; flexible
> > color schemas (keyword highlighting); keyboard events. Of course it will
> > work in such IDE cases, only if driver is a module.
> 
> But what I cannot understand is how you expect userspace to work while
> the lines are being displayed.

With `quiet' boot option no message bloat is flowing. I have on debian's
2.6.18 only two error message about PCI remaing error and if by buggy
grub didn't read initrd image correctly, so ungziping fails.

> If this is just to repaint the screen once everything is up, it is 100%
> useless. I'm interested in seeing errors _while_ they are happening.
> Basically, I need no color if the machine boots correctly.

OK. I don't know what somebody think it is like, let me show,
especially for our famous kernel developer.

In flower ftp upload adopted "init" script for initramfs can be found.
I took standard debian's and added  my stuff on head.

With quiet option kernel (should) very quickly reach initramfs/init.
Even 4M gzipped image (14M unpacked) on my laptop loads pretty quickly.

All is nice looking and scrollable (a bit). I didn't tried to do
separate scrolling regions for info and errors, because back scrolling
would be dead. But if somebody will fix this kernel feature, things
can be done easily then. Or file backup can used instead, early dmesg
available as a side effect.

So, i let see colored messages even for very old kernels, if this head
is added to initramfs/init. If it doesn't work for you, let's make it
work!

(sh: `sleep` must not be from busybox, because it has no seconds
fractions, which is kind of stupid, but POSIX compatible. My proposition
about select() like tool for shell can be found in google:
'olecom select sh')

== Script makes basic fs setup: ==============================

#!/bin/sh
# NOTE: pipefs (in <2.6.2?) isn't up yet
set +e

test  -e null || mknod null c 1 3
{
mkdir -m 0755 /dev
mkdir -m 1777 /tmp
mkdir -m 0555 /proc
cd /dev
mknod null c 1 3
mknod kmsg c 1 11
mknod tty  c 5 0
mknod console c 5 1
} 2>null

umask 077
mount -t proc proc /proc


== then TERM=linux tty loglevel attributes setup: ============

DEF='\033[0m'
EMERG='\033[1;5;37;41m' # bold blink white fore- on red background
ALERT='\033[1;37;41m'
CRIT='\033[1;5;31;40m'	# bold blink red on black
ERR='\033[1;31;40m'
WARN='\033[1;33;40m'	# bold yellow,
NOTICE='\033[1;36;40m'	# cyan
INFO='\033[1;32;40m'	# green
DBG='\033[1;34;40m'	# blue
q='\033[1;35m`'
b="\033[1;35m'"


== polling/printing daemon setup ================================

kttylog() {
# in case of rootfs change die
# (rerun manually in the end of the init script with new rootfs)
set -e
trap '
echo "reloading kttylogd, new pid=$!" >/dev/kmsg
exit
' EXIT HUP

while read -r LINE
   do case  "$LINE" in
    '<0'*) COLOR=EMERG;;
    '<1'*) COLOR=ALERT;;
    '<2'*) COLOR=CRIT;;
    '<3'*) COLOR=ERR;;
    '<4'*) COLOR=WARN;;
    '<5'*) COLOR=NOTICE;;
    '<7'*) COLOR=DBG;;
    esac
    # turn name to value
    eval 'printf "$'"${COLOR=INFO}"'"'
    # print raw content
    printf %s "${LINE#???}"
    # finish line output
    printf "$DEF\n\r"
done
}

== wait to see all "quiet" messages ==========================

printf "
After you've seen errors, even with $q\033[33mquiet$b$DEF option,
to see other (usual) printk() stuff and continue to boot,
please, hurry to press $q\033[0;1mEnter$b$DEF
"
fancy_read() {
TIMEOUT=7  # bash has seconds-only there, but we can have all,
	   # that (klibc's) `sleep' can (it has useful fractions, POSIX hasn't)
	   # Peter (hpa) did bash-incomatible change in klibc's `read`,
	   # added `-t', added with second fractions :(
	   # this functions is an example to show, that by means of `sh`
	   # it's possible to have *fancy* read (i.e. nice and flexible

POLLTIME=5 # tenths of seconds
TIMEOUT=${TIMEOUT}0
PROMPT="("
G=$((${#PROMPT} + 1))
PROMPT="$PROMPT$TIMEOUT): "

echo -n "$PROMPT"
exec 4<&0 # /dev/tty isn't working early, thus do dup of stdin for `read' job
( read LAMER_LEVEL || echo "Read Error" ) <&4 &
exec 4<&-

INPUT_PID=$!

while /bin/sleep 0.$POLLTIME && test -e "/proc/$INPUT_PID/exe"
do
   TIMEOUT=$((${TIMEOUT} - $POLLTIME))

   if test "$TIMEOUT" -gt 0
   then printf "\0337\033[${G}G$TIMEOUT): \0338"
   else printf "\033[${G}Gtime is out)"
        test -e "/proc/$INPUT_PID/exe" && kill $INPUT_PID
	break
   fi
done
}

fancy_read
unset fancy_read


== run printing daemon ==========================================

kttylog < /proc/kmsg >console &
KTTYLOG_PID=$!

cd /

== after flow of all pending messages, print this stuff==========

echo "<0>EMERG message (kmsg)..." >/dev/kmsg
echo "<1>ALERT message (kmsg)..." >/dev/kmsg
echo "<2>CRIT message (kmsg)..." >/dev/kmsg
echo "<3>ERR message (kmsg)..."  >/dev/kmsg
echo "<4>WARN message (kmsg)..." >/dev/kmsg
echo "<5>NOTICE message (kmsg)..." >/dev/kmsg
echo "<6>INFO message (kmsg)..." >/dev/kmsg
echo "<7>DBG message (kmsg)..." >/dev/kmsg
echo "
interactive shell (type exit to continue)

" >/dev/kmsg

== shell to have a bit of the rest =============================

sh -i

echo "Loading Debian..."

== continue booting ============================================

--- stuff ---

> Willy
> 

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

[Rene Herman]

On 10/07/2007 09:13 PM, Willy Tarreau wrote:

> On Sun, Oct 07, 2007 at 08:47:52PM +0200, Rene Herman wrote:

>> But well, there actually have been worse arguments given that VGA console 
>> is getting less and less important. I recently did a perusal of alternative 
>> distributions and didn't find a single one that didn't default to having a 
>> splash screen hide the kernel during boot (and if I'm not mistaken, only 
>> one of them provided me with the option during installation to not boot 
>> into X immediately afterwards).
> 
> I don't recall having seen any splash screen on Slackware.

Indeed, but that's the distribution I use and considered switching away 
from. Just my luck eh? :-\

> There are two distinct populations :
>   - those who are afraid of boot messages and prefer "splash" screens.
>     Those people are most common users, grown in non-IT environments. They
>     are happy to see a big logo on their BIOS to hide important boot errors,
>     and they are the ones who would never have imagined that pressing Escape
>     during the boot of windows 3.1/95 provided them with the full text
>     messages. Basically, they want to ensure they will never have to worry
>     about things they don't understand.

Nor want to understand, often.

>   - those who are troubleshooting their system in the early stages (kernel,
>     filesystems, network, services, ...). These ones *need* boot messages.
>     And there, depending on the hardware, sometimes the FB is better because
>     it shows larger lines, sometimes it's worse because the scrollback is
>     limited by too low memory.
> 
> I personally fit in the second category. And I'm sure most people on this
> list do.

As do I ofcourse. An operating system kernel development list might provide 
for a fairly non-average balanced population of "am / am not interested in 
the inner workings of computers". Given that most everyone these days uses a 
computer, it's still a really small percentage though -- and as evidenced by 
the bootsplash thing, even of Linux users (and I've in fact heard real-life 
people say they disliked the noisy Linux bootup due to "all those errors").

> I would be miserably sad if I couldn't get my boot messages anymore. It
> already irritates me a lot to loose the ones displayed before switching
> to frame-buffer when a hang happens just afterwards...

Oh quite. I use VGA console myself. But not being able to get to the bootup 
messages anymore even for people who do care is not the issue. It's about 
finding it a bit hard to get excited about colourization when the "obvious" 
way forward is so much more graphically oriented.

As also commented in another reply just now, ways forward also tend to have 
their problems but this kind of "innovation" takes me back to the time when 
our favorite bulletins board adopted ANSI colours. Today, that seems just a 
tad pathetic...

Again, it might not hurt any either, but sheesh.

Rene.

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

[Jan Engelhardt]

On Oct 7 2007 21:13, Willy Tarreau wrote:
>There are two distinct populations :
>  - those [...]
>    who would never have imagined that pressing Escape
>    during the boot of windows 3.1/95 provided them with the full text
>    messages.

This is news to me. DOS always showed messages, and under Win95,
it was either F8 or removing logo.sys. I did troubleshoot it ;-)

>  - those who are troubleshooting their system [...]
>
>I personally fit in the second category.
>
>I would say that while I'm not particularly fond of flashy colors
>everywhere

I have to agree so really. Just because there's a color option for 
everything does not mean one should use it.

In fact, I moved away[2] from the default Midnight Commander styling 
because it's just - as Dave calls it - salad colors[1].

Some is good, as long as it is not excessive. While I could imagine that 
Knoppix will abuse the feature and use vt.printk_color=9,9,9,9,11,10,12, 
this is not what serious people would do.

[1] http://tinyurl.com/yr9zgq
[2] http://tinyurl.com/234ba3

>, I think that being able to use colors to indicate particular
>actions in progress or conditions can be a good thing. RAID errors,
>devices disabled due to command-line parameters,

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

[Rene Herman]

On 10/07/2007 09:56 PM, Jan Engelhardt wrote:

> Some is good, as long as it is not excessive. While I could imagine that 
> Knoppix will abuse the feature and use vt.printk_color=9,9,9,9,11,10,12, 
> this is not what serious people would do.
> 
> [1] http://tinyurl.com/yr9zgq
> [2] http://tinyurl.com/234ba3

Given this discussion, I find it really appropriate that you are posting 
_graphics_ of your text screens :-)

Rene.

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

[Jan Engelhardt]

On Oct 7 2007 22:00, Rene Herman wrote:
> On 10/07/2007 09:56 PM, Jan Engelhardt wrote:
>
>> Some is good, as long as it is not excessive. While I could imagine that
>> Knoppix will abuse the feature and use vt.printk_color=9,9,9,9,11,10,12, this
>> is not what serious people would do.
>> 
>> [1] http://tinyurl.com/yr9zgq
>> [2] http://tinyurl.com/234ba3
>
> Given this discussion, I find it really appropriate that you are posting
> _graphics_ of your text screens :-)

I can give you a VCSA file (as produced by /dev/vcsa1) if you like,
complete with VCSA reader.

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

[Rene Herman]

On 10/07/2007 10:04 PM, Jan Engelhardt wrote:

> On Oct 7 2007 22:00, Rene Herman wrote:
>> On 10/07/2007 09:56 PM, Jan Engelhardt wrote:
>>
>>> Some is good, as long as it is not excessive. While I could imagine that
>>> Knoppix will abuse the feature and use vt.printk_color=9,9,9,9,11,10,12, this
>>> is not what serious people would do.
>>>
>>> [1] http://tinyurl.com/yr9zgq
>>> [2] http://tinyurl.com/234ba3
>> Given this discussion, I find it really appropriate that you are posting
>> _graphics_ of your text screens :-)
> 
> I can give you a VCSA file (as produced by /dev/vcsa1) if you like,
> complete with VCSA reader.

No, the PNGs will do thanks, it was obviuously a bit of a cheap shot. Still, 
it _is_ somewhat of a comment on what's expected these days.

Rene

tty UI (Re: [PATCH 0/2] Colored kernel output (run2))

[Oleg Verych]

On Sun, Oct 07, 2007 at 10:04:44PM +0200, Jan Engelhardt wrote:
> 
> On Oct 7 2007 22:00, Rene Herman wrote:
> > On 10/07/2007 09:56 PM, Jan Engelhardt wrote:
> >
> >> Some is good, as long as it is not excessive. While I could imagine that
> >> Knoppix will abuse the feature and use vt.printk_color=9,9,9,9,11,10,12, this
> >> is not what serious people would do.
> >> 
> >> [1] http://tinyurl.com/yr9zgq
> >> [2] http://tinyurl.com/234ba3
> >
> > Given this discussion, I find it really appropriate that you are posting
> > _graphics_ of your text screens :-)
> 
> I can give you a VCSA file (as produced by /dev/vcsa1) if you like,
> complete with VCSA reader.

In fact mc config (ini) section is a better way.

I use default blue (which is very annoying) for root user, to be aware of
possible results. Otherwise i use black background:

[Colors]
color_terminals=linux,xterm
base_color=normal=lightgray,black:marked=magenta,black:executable=green,black:directory=lightgray,black:editnormal=green,black:editbold=red,black

The most exiting event recently was, that `lynx` in debian got updated, so
it displays much more colors for HTML formatting now. I'm happy.
____

Re: tty UI (Re: [PATCH 0/2] Colored kernel output (run2))

[Jan Engelhardt]

On Oct 7 2007 22:50, Oleg Verych wrote:
>
>In fact mc config (ini) section is a better way.

Yes, for the default colors. But /usr/share/mc/syntax/ specifies
more of them.

>I use default blue (which is very annoying)

If blue were annoying, it would not be the default Windows background
(since Windows 2000). Then again, it's personal preference, so I suppose
you have a red/green desktop wallpaper for X11?

>The most exiting event recently was, that `lynx` in debian got updated, so
>it displays much more colors for HTML formatting now. I'm happy.

lynx. Update. Ha. Get w3m. Seriously. :)

Re: syntax highlighting, emacs ([PATCH 0/2] Colored kernel output (run2))

[Oleg Verych]

On Sun, Oct 07, 2007 at 10:43:46PM +0200, Jan Engelhardt wrote:
> 
> On Oct 7 2007 22:50, Oleg Verych wrote:
> >
> >In fact mc config (ini) section is a better way.
> 
> Yes, for the default colors. But /usr/share/mc/syntax/ specifies
> more of them.

Syntax highlighting, OK.

Kind of funny thing with it. One for shell in `mcedit` is much nicer, but
`emacs` is more powerful as editor(R). But both have highlighting
problems with non trivial scripts (quoiting, data here, etc). I don't
know if it will ever be fixed :).

Comprehensive highlighting of contents of diffs (or even _patched_
sources) is XXII century feature.

Anyway if anybody have anything to look onto, like more Linux C types,
bogus coding style highlighting, i'll be glad to test. And any
emacs hacks, that gurus are using will be very appreciated.

[0] emacs setup and fontlocking <ftp://flower.upol.cz/emacs/>

> >I use default blue (which is very annoying)
> 
> If blue were annoying, it would not be the default Windows background
> (since Windows 2000). Then again, it's personal preference,

Emacs have black background by default. I changed foreground to green,
and it is much nicer for long runs. Blue (or any bright) background
isn't comfortable, i think.

> so I suppose you have a red/green desktop wallpaper for X11?

Black background mostly. If you know classic blackbox wm (version <=
0.62), then Rancor(80%) and Artwiz(20%) my all time styles. But i use
no X for quite some time now.
____

Re: syntax highlighting, emacs ([PATCH 0/2] Colored kernel output (run2))

[Jan Engelhardt]

On Oct 8 2007 00:18, Oleg Verych wrote:
>
>Kind of funny thing with it. One for shell in `mcedit` is much nicer, but
>`emacs` is more powerful as editor(R). But both have highlighting
>problems with non trivial scripts (quoiting, data here, etc). I don't
>know if it will ever be fixed :).

No, it will never get fixed. I use two editors on a day-to-day basis,
and that is mcedit and joe. No fixed rule on which to use. It goes as
far that I have the same syntax highlighting (almost) on both.
Because one thing in one editor is cumbersome in the other.
Perhaps if there was one editor with the hotkeys of *both* (yes,
means duplicates), maybe then I'd be satisfied.

>Emacs have black background by default. I changed foreground to green,
>and it is much nicer for long runs. Blue (or any bright) background
>isn't comfortable, i think.

Actually, blue is perceived as one of the darkest colors by the human
eye. There is a reason that the RGB -> grayscale transformation uses
the following weighting: r=76 g=154 b=26.

Re: syntax highlighting, emacs ([PATCH 0/2] Colored kernel output (run2))

[Ken Moffat]

On Mon, Oct 08, 2007 at 12:11:21AM +0200, Jan Engelhardt wrote:
> 
> Actually, blue is perceived as one of the darkest colors by the human
> eye. There is a reason that the RGB -> grayscale transformation uses
> the following weighting: r=76 g=154 b=26.

 But, not every video card reproduces blue in the same way, let
alone every monitor - somewhere I've got an old CRT monitor where
blue text was mostly unreadable (_too_dark_).  For photo-editing,
I now use xgamma to get adequately-consistent results on whichever of
4 machines I'm using (one LCD monitor, with KVM switch) - the
settings for the individual machines are very different.

 And, of course, people have different colour vision (and unless we
are labelled as colour-blind, we each regard our colour vision as
"normal").  So, what is perfectly acceptable for you on specific
hardware may be totally unusable for someone else.

Ken
-- 
das eine Mal als Tragödie, das andere Mal als Farce

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

[Willy Tarreau]

On Sun, Oct 07, 2007 at 09:56:09PM +0200, Jan Engelhardt wrote:
> 
> On Oct 7 2007 21:13, Willy Tarreau wrote:
> >There are two distinct populations :
> >  - those [...]
> >    who would never have imagined that pressing Escape
> >    during the boot of windows 3.1/95 provided them with the full text
> >    messages.
> 
> This is news to me. DOS always showed messages, and under Win95,
> it was either F8 or removing logo.sys. I did troubleshoot it ;-)

You remember that you could start them both from DOS by typing "win" ?
If you hit ESC during the first seconds when the logo showed, you could
get back to text mode to see the messages.

> >  - those who are troubleshooting their system [...]
> >
> >I personally fit in the second category.
> >
> >I would say that while I'm not particularly fond of flashy colors
> >everywhere
> 
> I have to agree so really. Just because there's a color option for 
> everything does not mean one should use it.
> 
> In fact, I moved away[2] from the default Midnight Commander styling 
> because it's just - as Dave calls it - salad colors[1].

I found them "fun", it reminded me of the DOS-version of borland C, 15
years ago :-)

> Some is good, as long as it is not excessive. While I could imagine that 
> Knoppix will abuse the feature and use vt.printk_color=9,9,9,9,11,10,12, 
> this is not what serious people would do.

One solution against this and which may satisfy people who are against
this idea, would be to just manipulate the bold and reverse attributes
for errors. On VGA consoles, this would translate into printing in
white instead of grey, and it could also work on ANSI/vt100 terminals.

After all, if the initial intention was to report errors in a more
noticeable way, let's not let the user choose the colors and have
them defined the hard way. It will prevent the salad colors from
appearing.

Willy

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

[Ingo Molnar]

* Willy Tarreau <w@1wt.eu> wrote:

> I would say that while I'm not particularly fond of flashy colors 
> everywhere, I think that being able to use colors to indicate 
> particular actions in progress or conditions can be a good thing. RAID 
> errors, devices disabled due to command-line parameters, and general 
> anomalies which can cause a hang or panic a few line laters are worth 
> coloring. And I don't believe in userland's help here, because for 
> that type of messages, the indication should be returned immediately. 
> For instance, anyone who has experienced read errors on and IDE disk 
> knows that it can literally take hours/days to boot, after displaying 
> thousands of messages. Here, having the ability to see that no IRQ was 
> assigned or something like this could help.

Exactly. I'm also testing older distros quite regularly with new kernels 
and there's it's useful to have an impression of a kernel's output at a 
glance. Adding _any_ userspace change (even if i wanted to do it, which 
i dont) is out of question. So these are distinct, well-defined usecases 
that nobody has brought any coherent argument against yet. VGA isnt 
going away anytime soon, certainly not on my testboxes.

	Ingo

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

[Oleg Verych]

On Sun, Oct 07, 2007 at 11:11:54PM +0200, Ingo Molnar wrote:
> 
> * Willy Tarreau <w@1wt.eu> wrote:
> 
> > I would say that while I'm not particularly fond of flashy colors 
> > everywhere, I think that being able to use colors to indicate 
> > particular actions in progress or conditions can be a good thing. RAID 
> > errors, devices disabled due to command-line parameters, and general 
> > anomalies which can cause a hang or panic a few line laters are worth 
> > coloring. And I don't believe in userland's help here, because for 
> > that type of messages, the indication should be returned immediately. 
> > For instance, anyone who has experienced read errors on and IDE disk 
> > knows that it can literally take hours/days to boot, after displaying 
> > thousands of messages. Here, having the ability to see that no IRQ was 
> > assigned or something like this could help.
> 
> Exactly. I'm also testing older distros quite regularly with new kernels 
> and there's it's useful to have an impression of a kernel's output at a 
> glance.

> Adding _any_ userspace change (even if i wanted to do it, which i dont)
> is out of question.

TERM=linux attribute escape codes did not change for a decade (or so).

Making greping and coloring in userspace by means of klibc (+ GNU sed)
and initramfs will solve this easily, provided there's useful
kernel->console[userspace] interface. Ugly hacks, like those patches,
aren't for my view of an useful feature.

> So these are distinct, well-defined usecases that nobody has brought
> any coherent argument against yet. VGA isnt going away anytime soon,
> certainly not on my testboxes.

If you are not going to see OOPes of new kernels running old distros, ask
any perl hacker (as they lovely mentioned in lkml) to hack for you
something like:

sed -u -e '
/^<1/s_^_'$COLOR1'_
/^<2/s_^_'$COLOR2'_
/^<3/s_^_'$COLOR3'_
/^<4/s_^_'$COLOR4'_
/^<5/s_^_'$COLOR5'_
/^<6/s_^_'$COLOR6'_
/^<7/s_^_'$COLOR7'_
' < /proc/kmsg >/dev/tty

place whole that perl shit on initrams of your kernel, run it in
background as early as possible with switched off default console output
(i.e. quiet boot).

OVER.

For really good output it would be better to have escape code to
serialize printing, thus no coloring brain damage will appear in
concurrent writes on the tty (multiple areas, cursor movements). And this
is only start of what can be done here.
____

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

[Jan Engelhardt]

On Oct 8 2007 01:02, Oleg Verych wrote:
>
>If you are not going to see OOPes of new kernels running old distros, ask
>any perl hacker (as they lovely mentioned in lkml) to hack for you
>something like:
>
>sed -u -e '
>/^<1/s_^_'$COLOR1'_
>/^<2/s_^_'$COLOR2'_
>/^<3/s_^_'$COLOR3'_
>/^<4/s_^_'$COLOR4'_
>/^<5/s_^_'$COLOR5'_
>/^<6/s_^_'$COLOR6'_
>/^<7/s_^_'$COLOR7'_
>' < /proc/kmsg >/dev/tty
>
>place whole that perl shit on initrams of your kernel, run it in
>background as early as possible with switched off default console output
>(i.e. quiet boot).
>
>OVER.

Speaking of over, this does not fly at all. If you call panic(),
for whatever reason you want, then the printk() is the last thing
that happens after that, you can declare userspace dead.
On oopses, it depends on their severity. Eventually procfs goes
whoops and the kmsg transmission mechanism does not work, and oh,
userspace can't help it.

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

[Oleg Verych]

On Mon, Oct 08, 2007 at 01:01:33AM +0200, Jan Engelhardt wrote:
> 
> On Oct 8 2007 01:02, Oleg Verych wrote:
> >
> >If you are not going to see OOPes of new kernels running old distros, ask
> >any perl hacker (as they lovely mentioned in lkml) to hack for you
> >something like:
> >
> >sed -u -e '
> >/^<1/s_^_'$COLOR1'_
> >/^<2/s_^_'$COLOR2'_
> >/^<3/s_^_'$COLOR3'_
> >/^<4/s_^_'$COLOR4'_
> >/^<5/s_^_'$COLOR5'_
> >/^<6/s_^_'$COLOR6'_
> >/^<7/s_^_'$COLOR7'_
> >' < /proc/kmsg >/dev/tty
> >
> >place whole that perl shit on initrams of your kernel, run it in
> >background as early as possible with switched off default console output
> >(i.e. quiet boot).
> >
> >OVER.
> 
> Speaking of over, this does not fly at all. If you call panic(),
> for whatever reason you want, then the printk() is the last thing
> that happens after that, you can declare userspace dead.
> On oopses, it depends on their severity. Eventually procfs goes
> whoops and the kmsg transmission mechanism does not work, and oh,
> userspace can't help it.

I can rephrase/repeat: Here's discussion about general usage and feature
set.

The Development/debugging of the kernel, especially early boot or hard
core OOPs isn't covered. If a kernel developer wants to have nice looking
OOPes, i bet, this has nothing to do with general purpose printk() and
loglevels and the kernel, that usually must boot once, until next
security update.

This is just another debugging tool, that could be written faster than
any of the fancy rewrites of the kernel's core. Written many many
years ago with much reacher coloring features.
____

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

[Alistair John Strachan]

On Sunday 07 October 2007 20:13:09 you wrote:
> On Sun, Oct 07, 2007 at 08:47:52PM +0200, Rene Herman wrote:
> > On 10/07/2007 06:12 PM, Ingo Molnar wrote:
> > >* Oleg Verych <olecom@flower.upol.cz> wrote:
> > >>Coloring isn't useful. If it was, it would be implemented ~16 years
> > >>ago.
> > >
> > >Congratulations, this is the most stupid argument i've ever read on
> > >lkml.
> >
> > "Ay. World is finished. Everyone can go home and watch Friends reruns
> > now."
> >
> > But well, there actually have been worse arguments given that VGA console
> > is getting less and less important. I recently did a perusal of
> > alternative distributions and didn't find a single one that didn't
> > default to having a splash screen hide the kernel during boot (and if I'm
> > not mistaken, only one of them provided me with the option during
> > installation to not boot into X immediately afterwards).
>
> I don't recall having seen any splash screen on Slackware. And fortunately,
> the mainstream distros still provide the option to boot in text mode.

Debian defaultly doesn't use framebuffer or any kind of splash screen.

Splash screens are clearly cosmetic, and it's kind of shameful (imo) that 
important messages explaining real problems are obscured from view by 
functionless splash screens.

Personally, I think muddying the vga colour argument with splash screen stuff 
is bogus, they're very functionally separable ideas. A coloured oops seems to 
be a good way of telling novice users what information is relevant to their 
bug report.

-- 
Cheers,
Alistair.

137/1 Warrender Park Road, Edinburgh, UK.

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

[Rene Herman]

On 10/08/2007 12:40 AM, Alistair John Strachan wrote:

> Splash screens are clearly cosmetic, and it's kind of shameful (imo) that 
> important messages explaining real problems are obscured from view by 
> functionless splash screens.

They're not functionless. You (and I) might not care for the function, but 
their function is providing a "slick" bootup. That's why so many if not 
basically all distributions of recent origin use them. Go ask Ubuntu for 
example.

> Personally, I think muddying the vga colour argument with splash screen stuff 
> is bogus, they're very functionally separable ideas. A coloured oops seems to 
> be a good way of telling novice users what information is relevant to their 
> bug report.

But when they're hidden by a splash screen, you don't see them any better 
when they're red than when they're white. Splash screens were not mentioned 
as any sort of alternative, their prevalence was mentioned as indication 
that VGA console is only ever getting less important.

I find Alan's suggestion to provide the functionality the same way you'd 
provide for translated kernel messages (seeing as how there also are people 
that want those) much more sensible.

Rene.

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

[Alistair John Strachan]

On Monday 08 October 2007 00:10:10 Rene Herman wrote:
> On 10/08/2007 12:40 AM, Alistair John Strachan wrote:
> > Splash screens are clearly cosmetic, and it's kind of shameful (imo) that
> > important messages explaining real problems are obscured from view by
> > functionless splash screens.
>
> They're not functionless. You (and I) might not care for the function, but
> their function is providing a "slick" bootup. That's why so many if not
> basically all distributions of recent origin use them. Go ask Ubuntu for
> example.
>
> > Personally, I think muddying the vga colour argument with splash screen
> > stuff is bogus, they're very functionally separable ideas. A coloured
> > oops seems to be a good way of telling novice users what information is
> > relevant to their bug report.
>
> But when they're hidden by a splash screen, you don't see them any better
> when they're red than when they're white. Splash screens were not mentioned
> as any sort of alternative, their prevalence was mentioned as indication
> that VGA console is only ever getting less important.

Obviously true, but that's not a reason to bar enhancements to the VGA 
console. Right now, there's no sane way to have a splash screen in userspace 
handle an oops, so people looking to reproduce and detect the root of a 
problem will inevitably fall back to VGA (or vesa, presumably), where colour 
might be useful.

I recall seeing a distro kernel oops early in boot, where the palette had been 
corrupted by the splash so the oops wasn't readable. That's bad, right?

Don't get me wrong, I don't care for the feature much, I just don't 
think "splash screens are defacto" is a reason to shy away from a feature 
that could be useful for novices reporting kernel bugs. These people are 
probably inbetween those that must have a shiny splash and those that fix the 
kernel bugs.

Of course, what Alan said elsewhere about breaking things that work is a good 
reason to not add the feature, or at least make it only happen on a real 
display.

-- 
Cheers,
Alistair.

137/1 Warrender Park Road, Edinburgh, UK.

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

[Alistair John Strachan]

On Monday 08 October 2007 00:10:10 Rene Herman wrote:
> I find Alan's suggestion to provide the functionality the same way you'd
> provide for translated kernel messages (seeing as how there also are people
> that want those) much more sensible.

By the way, I agree that this is the best approach. Feasibly, it could be used 
by the same splash engines you mention to colour their console redirect, 
though most of the engines I've seen (e.g. SuSE/Ubuntu) don't let you switch 
messages on until after init (at which point kernel colours are probably 
irrelevant).

-- 
Cheers,
Alistair.

137/1 Warrender Park Road, Edinburgh, UK.

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

[Alan Cox]

> is bogus, they're very functionally separable ideas. A coloured oops seems to 
> be a good way of telling novice users what information is relevant to their 
> bug report.

Unless they are colour blind or on a system like a PDA with a mono
display 8)

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

[Jan Engelhardt]

On Oct 7 2007 13:10, Oleg Verych wrote:

>This `scrollback' is usual late boot / console one. If fact useful,
>until first tty switch or if `screen` cannot be used. But for some
>reason if scrolling region (DECSTBM) is less than whole screen, nothing
>works.

Actually, scrolling begins to work once userspace starts, and the
scrollback buffer (given enough size) still contains the first screenful
when Linux started, which may include the bootloader (if the loader did not
zero the screen before handing control over).

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

[Bill Davidsen]

Oleg Verych wrote:
> Hallo, Ingo.
> 
> On Sun, Oct 07, 2007 at 08:07:07AM +0200, Ingo Molnar wrote:

> 
> To clarify. `Scrollback' here is *useful* scrollback during early boot
> and OOPs (which is absent, AFAIK), "nothing like that" is coloring of the
> messages by loglevel.
> 
>> even if it were true (which it isnt), that is not an argument against 
>> including a useful change that exists now and that people are interested 
>> in.
> 
> Coloring isn't useful. If it was, it would be implemented ~16 years ago.

So anything that wasn't implemented a decade ago is not useful? Virtual 
machines, software raid, fair scheduling, jumbo packets, SMT/SMP/NUMA 
support, support for >4GB physical memory on x86, all fluff?
> 
>> (and yes, i have implemented kernel console improvements in the past 
>> and vga scrollback support was in fact amongst one of my first ever 
>> Linux kernel hacks so your comment is doubly wrong.)
> 
> This `scrollback' is usual late boot / console one. If fact useful,
> until first tty switch or if `screen` cannot be used. But for some
> reason if scrolling region (DECSTBM) is less than whole screen, nothing
> works. And if width set to odd number of columns
> 
> `stty columns $((80-1))`
> 
> whole output becomes somewhat funny.

I think by the time you get up enough to be running ill-advised commands 
from shell, you are past "early boot." Your comments about scrollback 
not working right if you break it are hopefully an attempt at humor.

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

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

[Oleg Verych]

Hi, Bill.

Fri, Oct 12, 2007 at 09:16:01AM -0400:
[]
> >Coloring isn't useful. If it was, it would be implemented ~16 years ago.
> 
> So anything that wasn't implemented a decade ago is not useful? Virtual 
> machines, software raid, fair scheduling, jumbo packets, SMT/SMP/NUMA 
> support, support for >4GB physical memory on x86, all fluff?

Are we talking about VGA text mode or VT100 terminals? On what arch
Linux was written to run shell and to build itself?

IBM PC, if you don't know. Thus, your comment isn't funny or serious,
sorry. I also distinguish important, needed, useful, preferable.

> >>(and yes, i have implemented kernel console improvements in the past 
> >>and vga scrollback support was in fact amongst one of my first ever 
> >>Linux kernel hacks so your comment is doubly wrong.)
> >
> >This `scrollback' is usual late boot / console one. If fact useful,
> >until first tty switch or if `screen` cannot be used. But for some
> >reason if scrolling region (DECSTBM) is less than whole screen, nothing
> >works. And if width set to odd number of columns
> >
> >`stty columns $((80-1))`
> >
> >whole output becomes somewhat funny.
> 
> I think by the time you get up enough to be running ill-advised commands 
> from shell, you are past "early boot."

As i did dumb userspace coloring of kernel messages after this post,
where text from bootloader, critical stuff are visible -- i.e. no
truncated scrollback is needed, i can say, that this comment is bogus.

I don't know what `ill-advised' commands are, but knowing how pipefs
wasn't up early in <2.6.2X, i can say: *IT IS EARLY*. By me anything,
that have /dev/console as controlling tty is early.

> Your comments about scrollback not working right if you break it are
> hopefully an attempt at humor.

Cannot comment, because i don't understand this. I want scrollback in a
defined scrolling region; i what line scrolling not be cursed, if columns
number is odd.

Now i have all this in userspace *early*, so i don't care about what
ever implementors of that stuff in kernel thought.

Bye.
--
-o--=O`C
 #oo'L O
<___=E M