public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Peterson <dsp@llnl.gov>
To: Arjan van de Ven <arjan@infradead.org>
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
Subject: Re: [PATCH] EDAC: core EDAC support code
Date: Fri, 10 Mar 2006 11:07:27 -0800	[thread overview]
Message-ID: <200603101107.27244.dsp@llnl.gov> (raw)
In-Reply-To: <1142013481.2876.89.camel@laptopd505.fenrus.org>

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.

    Scenario B
    ----------
    A more centralized layout.  Here, the controls that govern a wide
    variety of error handling behaviors are all grouped together (for
    instance, within EDAC).

I tend to prefer scenario A.  The conceptual model I currently have in
my mind for EDAC is as follows:

    - Each low-level EDAC module (amd76x, e7xxx, etc.) implements
      hardware error handling functionality that is specific to just
      that platform.

    - The purpose of the core EDAC module is to serve as a home for
      abstractions that are common to the various low-level EDAC
      modules.  This creates uniformity of mechanism, and also uniform
      behavior from the user's point of view.  It also encourages
      avoidance of replicated code.  However, the core EDAC module
      (and by extension, the low-level EDAC modules) should not
      contain stuff that is generic enough to fit elsewhere (for
      instance, in the PCI subsystem).  In other words, EDAC serves as
      a catch-all for error handling functionality that is too
      platform-specific to fit anywhere else.

However, these are just my personal thoughts.  I'd be curious to hear
other ideas people may have.


  reply	other threads:[~2006-03-10 19:08 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200601190414.k0J4EZCV021775@hera.kernel.org>
2006-03-05 10:18 ` [PATCH] EDAC: core EDAC support code Arjan van de Ven
2006-03-05 10:30   ` Arjan van de Ven
2006-03-06 18:14     ` Dave Peterson
2006-03-06 18:22       ` Randy.Dunlap
2006-03-07 17:03         ` Dave Peterson
2006-03-07 17:20           ` Greg KH
2006-03-08  0:29             ` Dave Peterson
2006-03-07 19:03           ` Arjan van de Ven
2006-03-07 19:05             ` Greg KH
2006-03-09 23:51             ` Dave Peterson
2006-03-10  0:02               ` Greg KH
2006-03-10  1:46                 ` Dave Peterson
2006-03-10  7:36                   ` Arjan van de Ven
2006-03-10 11:06                     ` Tim Small
2006-03-10 11:40                       ` Arjan van de Ven
2006-03-10 17:46                     ` Dave Peterson
2006-03-10 17:58                       ` Arjan van de Ven
2006-03-10 19:07                         ` Dave Peterson [this message]
2006-03-10 19:33                           ` Arjan van de Ven
2006-03-10 21:13                             ` Dave Peterson
2006-03-10 21:23                               ` Arjan van de Ven
2006-03-11  1:57                                 ` Dave Peterson
2006-03-11  7:18                                   ` Arjan van de Ven
2006-03-13 19:31                                     ` Dave Peterson
2006-03-06 19:52       ` Greg KH
2006-03-05 15:55   ` Greg KH
2006-03-05 16:24     ` Arjan van de Ven
2006-03-06 18:52     ` Dave Peterson
2006-03-06 19:53       ` Greg KH
2006-03-06 21:01         ` Dave Peterson
2006-03-06 21:07           ` Arjan van de Ven
2006-03-09  3:19             ` Dave Peterson
2006-03-09  3:44               ` Al Viro
2006-03-09  5:51               ` Greg KH
2006-03-06 21:32           ` Al Viro
2006-03-06 21:53             ` Greg KH
2006-03-06 22:24               ` Al Viro
2006-03-06 22:55                 ` Greg KH
2006-03-07 10:41                 ` Andrew Morton
2006-03-07 11:08                   ` Al Viro
2006-03-08  2:46                   ` Rusty Russell
2006-03-07  1:45               ` Dmitry Torokhov
2006-03-07  1:57                 ` Greg KH
2006-03-07  2:10                   ` Dmitry Torokhov
2006-03-07 16:47             ` Dave Peterson
2006-03-07 17:04               ` Greg KH
2006-03-07 17:06                 ` Dave Peterson
2006-03-08  1:03                 ` Dmitry Torokhov
2006-03-08  1:33                   ` Greg KH
2006-03-10  0:44 Doug Thompson
  -- strict thread matches above, loose matches on Subject: below --
2006-03-10 16:56 Doug Thompson
2006-03-10 17:11 ` Arjan van de Ven
2006-03-10 17:28 Doug Thompson
2006-03-10 20:37 Doug Thompson
2006-03-11 17:04 Doug Thompson
2006-03-13 19:35 ` Dave Peterson

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=200603101107.27244.dsp@llnl.gov \
    --to=dsp@llnl.gov \
    --cc=alan@redhat.com \
    --cc=arjan@infradead.org \
    --cc=bluesmoke-devel@lists.sourceforge.net \
    --cc=dthompson@lnxi.com \
    --cc=greg@kroah.com \
    --cc=gregkh@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rdunlap@xenotime.net \
    --cc=torvalds@osdl.org \
    /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