[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=FV=XUWnjCAjZKb5wYcGhC=T8+hoUr+1junoH5ognge1aZHg@mail.gmail.com>
Date: Fri, 16 Jun 2023 09:44:01 -0700
From: Doug Anderson <dianders@...omium.org>
To: Petr Mladek <pmladek@...e.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
kgdb-bugreport@...ts.sourceforge.net, linux-kernel@...r.kernel.org,
Nicholas Piggin <npiggin@...il.com>,
Michael Ellerman <mpe@...erman.id.au>,
linuxppc-dev@...ts.ozlabs.org,
Christophe Leroy <christophe.leroy@...roup.eu>,
sparclinux@...r.kernel.org,
"David S . Miller" <davem@...emloft.net>,
linux-perf-users@...r.kernel.org
Subject: Re: [PATCH v2 1/6] watchdog/hardlockup: Sort hardlockup detector
related config values a logical way
Hi,
On Fri, Jun 16, 2023 at 8:06 AM Petr Mladek <pmladek@...e.com> wrote:
>
> There are four possible variants of hardlockup detectors:
>
> + buddy: available when SMP is set.
>
> + perf: available when HAVE_HARDLOCKUP_DETECTOR_PERF is set.
>
> + arch-specific: available when HAVE_HARDLOCKUP_DETECTOR_ARCH is set.
>
> + sparc64 special variant: available when HAVE_NMI_WATCHDOG is set
> and HAVE_HARDLOCKUP_DETECTOR_ARCH is not set.
>
> Only one hardlockup detector can be compiled in. The selection is done
> using quite complex dependencies between several CONFIG variables.
> The following patches will try to make it more straightforward.
>
> As a first step, reorder the definitions of the various CONFIG variables.
> The logical order is:
>
> 1. HAVE_* variables define available variants. They are typically
> defined in the arch/ config files.
>
> 2. HARDLOCKUP_DETECTOR y/n variable defines whether the hardlockup
> detector is enabled at all.
>
> 3. HARDLOCKUP_DETECTOR_PREFER_BUDDY y/n variable defines whether
> the buddy detector should be preferred over the perf one.
> Note that the arch specific variants are always preferred when
> available.
>
> 4. HARDLOCKUP_DETECTOR_PERF/BUDDY variables define whether the given
> detector is enabled in the end.
>
> 5. HAVE_HARDLOCKUP_DETECTOR_NON_ARCH and HARDLOCKUP_DETECTOR_NON_ARCH
> are temporary variables that are going to be removed in
> a followup patch.
>
> This is a preparation step for further cleanup. It will change the logic
> without shuffling the definitions.
>
> This change temporary breaks the C-like ordering where the variables are
> declared or defined before they are used. It is not really needed for
> Kconfig. Also the following patches will rework the logic so that
> the ordering will be C-like in the end.
>
> The patch just shuffles the definitions. It should not change the existing
> behavior.
>
> Signed-off-by: Petr Mladek <pmladek@...e.com>
> ---
> lib/Kconfig.debug | 112 +++++++++++++++++++++++-----------------------
> 1 file changed, 56 insertions(+), 56 deletions(-)
Reviewed-by: Douglas Anderson <dianders@...omium.org>
Powered by blists - more mailing lists