[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20161020202527.b01839356c6d34ed0cba3569@linux-foundation.org>
Date: Thu, 20 Oct 2016 20:25:27 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Don Zickus <dzickus@...hat.com>
Cc: Babu Moger <babu.moger@...cle.com>, mingo@...nel.org,
ak@...ux.intel.com, jkosina@...e.cz,
baiyaowei@...s.chinamobile.com, atomlin@...hat.com,
uobergfe@...hat.com, tj@...nel.org, hidehiro.kawai.ez@...achi.com,
johunt@...mai.com, davem@...emloft.net, sparclinux@...r.kernel.org,
linux-kernel@...r.kernel.org, sam@...nborg.org
Subject: Re: [PATCH v2 1/2] watchdog: Introduce arch_watchdog_nmi_enable and
arch_watchdog_nmi_disable
On Thu, 20 Oct 2016 12:14:14 -0400 Don Zickus <dzickus@...hat.com> wrote:
> > > -static int watchdog_nmi_enable(unsigned int cpu) { return 0; }
> > > -static void watchdog_nmi_disable(unsigned int cpu) { return; }
> > > +/*
> > > + * These two functions are mostly architecture specific
> > > + * defining them as weak here.
> > > + */
> > > +int __weak arch_watchdog_nmi_enable(unsigned int cpu) { return 0; }
> > > +void __weak arch_watchdog_nmi_disable(unsigned int cpu) { return; }
> > > +
> > > #endif /* CONFIG_HARDLOCKUP_DETECTOR */
> >
> > This is a strange way of using __weak.
> >
> > Take a look at (one of many examples) kernel/module.c:module_alloc().
> > We simply provide a default implementation and some other compilation
> > unit can override (actually replace) that at link time. No strange
> > ifdeffing needed.
>
> Yeah, this is mostly because of how we enable the hardlockup detector.
>
> Some arches use the perf hw and enable CONFIG_HARDLOCKUP_DETECTOR. Other
> arches just use their own variant of nmi and set CONFIG_HAVE_NMI_WATCHDOG and
> the rest of the arches do not use this.
>
> So the thought was if CONFIG_HARDLOCKUP_DETECTOR use that implementation,
> everyone else use the __weak version. Then the arches like sparc can override
> the weak version with their own nmi enablement.
>
> I don't know how to represent those 3 states correctly and the above is what
> we end up with.
<head spins>
Is there a suitable site where we could capture these considerations in
a code comment?
Powered by blists - more mailing lists