On Tue, Feb 23, 2021 at 09:41:40AM -0800, Guenter Roeck wrote: > > I tried to explain why we don't want to set COMPILE_TEST for s390 > > anymore. It overrides architecture dependencies in Kconfig, and lots > > of drivers do not set dependencies for HAS_IOMEM, HAS_DMA, and friends > > correctly. > > This generates constantly fallout which is irrelevant for s390 and > > also for other architectures. It generates just work with close to > > zero benefit. For drivers which matter for s390 we still see those > > errors. > > > > > On the other side, if that flag would be set explicitly by > > > all{yes,mod}config, it would really beg for being misused. We > > > might then as well add a new flag that is explicitly associated > > > with all{yes,mod}config, but not with randconfig. > > > > I think that makes most sense, probably also have a flag that is set > > for randconfig. > > Not sure what value such an option would have, and how it would be used. > I would argue that randconfig should not set COMPILE_TEST to start with, > since its purpose should be to test random valid configurations and not > to compile test arbitrary (and in that case random) code. But that is > a different question, and just my personal opinion. > > Overall, the question is what kind of additional option you would find > useful for s390. You make it clear that you don't want COMPILE_TEST. > At the same time, you still want all{mod,yes}config, but presumably > excluding options currently restricted by !COMPILE_TEST (such as > DEBUG_INFO, BPF_PRELOAD, UBSAN_TRAP, GCC_PLUGIN_CYC_COMPLEXITY, > and a few others). SUPPRESS_NOISY_TESTS would not cover that, but > neither would RANDCONFIG (or whatever it would be called).
Well, if we would have e.g. RANDCONFIG, then we could probably revert 334ef6ed06fa ("init/Kconfig: make COMPILE_TEST depend on !S390") and instead let COMPILE_TEST depend on !RANDCONFIG. I think this _could_ solve all common problems we currently see. And it would also do what you suggested.