public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Len Brown <lenb@kernel.org>
Cc: Mark Lord <kernel@teksavvy.com>,
	Huang Ying <ying.huang@intel.com>,
	huang ying <huang.ying.caritas@gmail.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Andi Kleen <andi@firstfloor.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>, Borislav Petkov <bp@alien8.de>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 0/2] Generic hardware error reporting support
Date: Tue, 30 Nov 2010 13:09:14 -0200	[thread overview]
Message-ID: <4CF5139A.1080607@redhat.com> (raw)
In-Reply-To: <alpine.LFD.2.00.1011242320000.637@x980>

Em 25-11-2010 02:27, Len Brown escreveu:
>> ... most *NIX tools store and manage data in _text_ form.
> 
> If the hardware error dump is complicated there is a trade-off
> between making things human readable and putting a lot of
> comlicated parsing code into the kernel.  Maybe the kernel
> should just dump hex "text" in some cases and let a user-program
> parse the syslog?
> 
> What do do if the hardware error log is very large?
> Is there a limit on how much is practical to send through syslog?

If you look what sysadm's do with the Unix logs, you'll see that they 
use either one of the following approaches:

1) have something looking at syslog (and/or serial console logs), and 
storing them for their analisys, in text format;

2) convert syslog errors into a SNMP object UID's, on a machine-readable code, 
in order to manage them via some SNMP management system.

On both cases, the approach is there for a long time.

If an error "magic" code is added, both ways will break, as sysadm's won't be
able to understand the meaning of the magic number, and the SNMP conversion 
tools won't be ready to convert that magic code into something else. 

Of course, with time, the SNMP parsers will eventually add the needed decoders
for the magic numbers, in order to convert them into a MIB representation.

So, even being a number, such code is not machine readable (at least not for the
right tools), as it is not an SNMP object, so, the management systems won't catch 
it without a parser.

So, IMO, the better is to keep providing a text message. 

We might think on adding a way to directly output a SNMP UID from kernel,
but this seems overkill to me, and anything else would just be meaningless
for most sysadmins.

Thanks,
Mauro.

  reply	other threads:[~2010-11-30 15:10 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-19  8:10 [PATCH 0/2] Generic hardware error reporting support Huang Ying
2010-11-19  8:10 ` [PATCH 1/2] Generic hardware error reporting mechanism Huang Ying
2010-11-19  8:45   ` Huang Ying
2010-11-19 13:56   ` boris
2010-11-20  2:52     ` huang ying
2010-11-20  9:00       ` Borislav Petkov
2010-11-20 11:51         ` huang ying
2010-11-19  8:10 ` [PATCH 2/2] Hardware error record persistent support Huang Ying
2010-11-19 15:52   ` Linus Torvalds
2010-11-19 20:01     ` Andrew Morton
2010-11-20  1:09     ` huang ying
2010-11-19  8:13 ` [PATCH 0/2] Generic hardware error reporting support Huang Ying
2010-11-19 11:22 ` Peter Zijlstra
2010-11-19 11:54   ` huang ying
2010-11-19 12:02     ` Peter Zijlstra
2010-11-19 12:48       ` huang ying
2010-11-19 12:55         ` Peter Zijlstra
2010-11-19 13:06           ` huang ying
2010-11-19 13:18             ` Peter Zijlstra
2010-11-19 13:28               ` huang ying
2010-11-19 13:37                 ` Peter Zijlstra
2010-11-19 13:49                   ` huang ying
2010-11-19 15:56 ` Linus Torvalds
2010-11-20  2:04   ` huang ying
2010-11-20  2:15     ` Linus Torvalds
2010-11-20  7:11       ` huang ying
2010-11-20 13:39         ` Mark Lord
2010-11-20 23:44           ` huang ying
2010-11-25  4:19           ` Len Brown
     [not found]         ` <AANLkTinAZgHbexU+LTUZHs-+7C0N990=kyuO-USV1Ncp@mail.gmail.com>
2010-11-20 23:57           ` Linus Torvalds
2010-11-21  0:42             ` huang ying
2010-11-21  0:50               ` Linus Torvalds
2010-11-21  1:06                 ` huang ying
2010-11-22 23:43                   ` Mark Lord
2010-11-23  0:29                     ` Huang Ying
2010-11-25  2:41                       ` Mark Lord
2010-11-25  4:27                         ` Len Brown
2010-11-30 15:09                           ` Mauro Carvalho Chehab [this message]
2010-11-25  4:35                         ` Huang Ying
2010-11-21  0:50   ` Elias Gabriel Amaral da Silva

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CF5139A.1080607@redhat.com \
    --to=mchehab@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=bp@alien8.de \
    --cc=huang.ying.caritas@gmail.com \
    --cc=kernel@teksavvy.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=ying.huang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox