Messages in this thread | | | Date | Mon, 7 Nov 2022 10:20:43 -0800 | From | Yury Norov <> | Subject | Re: [PATCH v2] cpumask: limit visibility of FORCE_NR_CPUS |
| |
On Mon, Nov 07, 2022 at 09:55:34AM -0800, Linus Torvalds wrote: > On Mon, Nov 7, 2022 at 4:45 AM Valentin Schneider <vschneid@redhat.com> 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.
Thanks, I'll send v3 than.
Thanks, Yury
| |