Re: [PATCH v2] cpumask: limit visibility of FORCE_NR_CPUS

[Linus Torvalds]

On Mon, Nov 7, 2022 at 4:45 AM Valentin Schneider <vschneid@xxxxxxxxxx> wrote:
>
> True, this would have been neater as a single config, but AIUI it's a
> required "trick" for allyesconfig. I would have expected other configs to
> have hit similar issues in the past, but didn't find any.

Actually, the standard trick for allmodconfig and allyesconfig is to
use the "COMPILE_TEST" config variable.

It's basically a variable for "I'm not going to *run* the result, but
I want to make sure to get build coverage".

And both allmodconfig and allyesconfig set that config option.

In most cases, the "COMPILE_TEST" config variable is used to enable
things that wouldn't make sense on the chosen hardware platform, so
you have things like

        depends on ARCH_DAVINCI || COMPILE_TEST

because some driver only makes sense on ARCH_DAVINCI, but people still
want the build coverage.

But sometimes it's used the other way around, so fro example on x86 we have

     config X86_DECODER_SELFTEST

which explicitly depends on COMPILE_TEST *not* being set, because it's
a test that takes forever to run (particularly for huge kernels), and
so it's actually disabled for the  common all{yes,mod}config cases.

Same goes for things like LTO_CLANG_FULL. It's just expensive for big
build tests, plus causes too many issues for now.

End result: if some option actually *reduces* test coverage, or has
some other reason why it makes no sense for build tests, use that

        depends on !COMPILE_TEST

to not have allmodconfig and allyesconfig pick it.

                    Linus