[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7149.1191771990@turing-police.cc.vt.edu>
Date: Sun, 07 Oct 2007 11:46:30 -0400
From: Valdis.Kletnieks@...edu
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: Oleg Verych <olecom@...wer.upol.cz>, Ingo Molnar <mingo@...e.hu>,
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)"
(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...)
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists