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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 7 Oct 2007 23:11:54 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Willy Tarreau <w@....eu>
Cc:	Rene Herman <rene.herman@...access.nl>,
	Oleg Verych <olecom@...wer.upol.cz>,
	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"


* 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. 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
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ