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

Oleg Verych
2007-10-07T22:48:50Z

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