From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andi Kleen Subject: Re: [NAK] Re: [PATCH -v2 9/9] ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support Date: Mon, 25 Oct 2010 15:11:27 +0200 Message-ID: <20101025131127.GC17622@basil.fritz.box> References: <1287992610-14996-1-git-send-email-ying.huang@intel.com> <1287992610-14996-10-git-send-email-ying.huang@intel.com> <20101025084553.GA27119@elte.hu> <1287997112.2862.322.camel@yhuang-dev> <20101025091913.GA17622@basil.fritz.box> <20101025111530.GA27659@elte.hu> <20101025123753.GB17622@basil.fritz.box> <20101025125531.GA6075@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from one.firstfloor.org ([213.235.205.2]:36021 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750764Ab0JYNL3 (ORCPT ); Mon, 25 Oct 2010 09:11:29 -0400 Content-Disposition: inline In-Reply-To: <20101025125531.GA6075@elte.hu> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Ingo Molnar Cc: Andi Kleen , Huang Ying , Len Brown , "linux-kernel@vger.kernel.org" , "linux-acpi@vger.kernel.org" , Borislav Petkov , Thomas Gleixner , "H. Peter Anvin" , Don Zickus , Linus Torvalds , Andrew Morton , Mauro Carvalho Chehab , Arjan van de Ven On Mon, Oct 25, 2010 at 02:55:31PM +0200, Ingo Molnar wrote: > > * Andi Kleen wrote: > > > On Mon, Oct 25, 2010 at 01:15:30PM +0200, Ingo Molnar wrote: > > > > > > > > einj.c: it's about the 3rd separate 'error injection' concept that got > > > > > > introduced ... > > > > > > > > > > EINJ is a true platform feature, not just software feature. We need to support > > > > > it to debug various hardware error features. > > > > > > > > Also having multiple error injecting interfaces is a good thing. > > > > > > It's never a good thing to have separate, vendor dependent interfaces for what > > > to the user is basically the same conceptual thing! > > > > Perhaps a simple example (simplified, in practice there are more complications) > > makes it more clear: > > > > The memory error handler does different actions depending on what the state the > > page the error is happening on is in. > > What you appear to be arguing for is the ability to inject different types of > events. Different events in different contexts with different drivers with different parameters using different tools. Commonality: about 0% exept there's "error" somewhere in the description. -Andi