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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071007230250.GV22435@flower.upol.cz>
Date:	Mon, 8 Oct 2007 01:02:50 +0200
From:	Oleg Verych <olecom@...wer.upol.cz>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Willy Tarreau <w@....eu>, Rene Herman <rene.herman@...access.nl>,
	Jan Engelhardt <jengelh@...putergmbh.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Dave Jones <davej@...hat.com>,
	Krzysztof Halasa <khc@...waw.pl>,
	Medve Emilian-EMMEDVE1 <Emilian.Medve@...escale.com>,
	Helge Deller <deller@....de>
Subject: Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

On Sun, Oct 07, 2007 at 11:11:54PM +0200, Ingo Molnar wrote:
> 
> * Willy Tarreau <w@....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.
____
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/