Hi, On Fri, Jun 16, 2023 at 8:06 AM Petr Mladek <pmladek@xxxxxxxx> 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@xxxxxxxx> > --- > lib/Kconfig.debug | 112 +++++++++++++++++++++++----------------------- > 1 file changed, 56 insertions(+), 56 deletions(-) Reviewed-by: Douglas Anderson <dianders@xxxxxxxxxxxx>
