[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1274209051.17703.110.camel@Joe-Laptop.home>
Date: Tue, 18 May 2010 11:57:31 -0700
From: Joe Perches <joe@...ches.com>
To: Andi Kleen <andi@...stfloor.org>
Cc: Mauro Carvalho Chehab <mchehab@...hat.com>,
Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
bluesmoke-devel@...ts.sourceforge.net,
Linux Edac Mailing List <linux-edac@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Ben Woodard <woodard@...hat.com>,
Matt Domsch <Matt_Domsch@...l.com>,
Doug Thompson <dougthompson@...ssion.com>,
Borislav Petkov <bp@...64.org>,
Tony Luck <tony.luck@...el.com>,
Brent Young <brent.young@...el.com>
Subject: Re: Hardware Error Kernel Mini-Summit
On Tue, 2010-05-18 at 20:45 +0200, Andi Kleen wrote:
> Joe Perches <joe@...ches.com> writes:
> > On Tue, 2010-05-18 at 13:44 -0300, Mauro Carvalho Chehab wrote:
> >> IMO, the first
> >> step is to provide an error core integrated to perf, and then start
> >> integrating the several error systems around it.
> > Why integrated to perf?
> For a different perspective on this see also
> http://permalink.gmane.org/gmane.linux.kernel/952061
>
> AFAIK all the issues mentioned there are still open.
Yup, that's why I asked for explanation.
What was offered lacks useful goal and design detail.
perf is a cool tool, but probably not necessary for
for a HW error reporting system.
--
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