Subject: Re: [PATCH] EDAC: core EDAC support code
From: Arjan van de Ven <arjan@infradead.org>
To: Dave Peterson <dsp@llnl.gov>
Cc: Greg KH <greg@kroah.com>, "Randy.Dunlap" <rdunlap@xenotime.net>,
       linux-kernel@vger.kernel.org, torvalds@osdl.org, alan@redhat.com,
       gregkh@kroah.com, Doug Thompson <dthompson@lnxi.com>,
       bluesmoke-devel@lists.sourceforge.net
In-Reply-To: <200603101107.27244.dsp@llnl.gov>
References: <200601190414.k0J4EZCV021775@hera.kernel.org>
	 <200603100946.12448.dsp@llnl.gov>
	 <1142013481.2876.89.camel@laptopd505.fenrus.org>
	 <200603101107.27244.dsp@llnl.gov>
Content-Type: text/plain
Date: Fri, 10 Mar 2006 20:33:15 +0100
Message-Id: <1142019195.2876.100.camel@laptopd505.fenrus.org>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1715
Lines: 46

On Fri, 2006-03-10 at 11:07 -0800, Dave Peterson wrote:
> On Friday 10 March 2006 09:58, Arjan van de Ven wrote:
> > > I'd be curious to hear people's opinions on the following idea:
> > > move the PCI bus parity error checking functionality from EDAC
> > > to the PCI subsystem.
> >
> > I can see the point on at least moving all the infrastructure there.
> > The actual call to run it... maybe. that's more debatable I suppose.
> 
> Regarding the actual call to run it, I guess it depends on which of
> the following you prefer:
> 
>     Scenario A
>     ----------
>     A more decentralized layout.  Here, the controls that govern the
>     error handling behavior for a given category of hardware (a
>     category might be "PCI devices" or "devices that use bus
>     technology XYZ") are grouped together with other stuff for that
>     category.

this would basically make edac a place to report "help something went to
the gutter". Sure. I see that useful. 

In fact there are 3 layers then

1) low level "do check" function

2) per bus code that calls the do check functions and whatever is needed
for bus checks

3) "EDAC" central command, which basically gathers all failure reports
and does something with them (push them to userspace or implement the
userspace chosen policy (panic/reboot/etc))


having 1) separate from 2) is useful, it means that drivers can do
synchronous checks in addition to the checks in 2) which will tend to be
asynchronous....


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/