Date: Fri, 3 Mar 2006 16:03:58 -0800
From: Andrew Morton <akpm@osdl.org>
To: Dave Peterson <dsp@llnl.gov>
Cc: dthompson@lnxi.com, arjan@infradead.org,
       bluesmoke-devel@lists.sourceforge.net, hch@lst.de,
       alan@lxorguk.ukuu.org.uk, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/15] EDAC: switch to kthread_ API
Message-Id: <20060303160358.57197d23.akpm@osdl.org>
In-Reply-To: <200603031520.29855.dsp@llnl.gov>
References: <4408050A0200003600000CC8@zoot.lnxi.com>
	<200603031520.29855.dsp@llnl.gov>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1265
Lines: 30

Dave Peterson <dsp@llnl.gov> wrote:
>
> On Friday 03 March 2006 07:57, Doug Thompson wrote:
> > Currently the timer event code performs two operations:
> >
> >   1) ECC polling and
> >   2) PCI parity polling.
> >
> > I want to split those from each other, so each can have a seperate cycle
> > rate (also adding a sysfs cycle control for the PCI parity timing in
> > addition to the existing ECC cycle control).
> 
> Yes, this sounds like a good idea.  Using schedule_delayed_work() to
> independently implement each polling cycle, we should be able to get
> rid of the EDAC kernel thread.

That would suit.  One needs to be quite careful about killing everything
off in the close->rmmod side of things, especially if the delayed work
handler re-arms itself.  We have a pending (and possibly executing) timer
handler to worry about, then a pending (and possibly executing) keventd
handler to worry about.

We've got this cancel_rearming_delayed_work() thing - I was never terribly
happy about it, but I think it works.

-
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/