On 8/18/26 2:23 PM, Gary Guo wrote: > On Tue Aug 18, 2026 at 9:44 PM BST, Miguel Ojeda wrote: >> On Tue, Aug 18, 2026 at 5:23 PM Yury Norov <[email protected]> wrote: >>> >>> Make every Rust KUnit test suite require the Kconfig option that controls >>> it, and let the `kunit_tests` macro apply the corresponding `#[cfg]` >>> attribute. >> >> If we are sure we always want at least one `cfg` guarding them, then >> yeah, this makes sense (we could ask to write the `cfg` bit inside, >> for "greppability", and for clarity / less ambiguity later on). >> >> David: are there cases on KUnit where you would recommend/prefer >> something different? >> >> For instance, I could imagine a Rust `mod` for testing purposes >> already gated by a `cfg` that is meant to contain many tests, and then >> different suites inside that for control (possibly with extra `cfg`s, >> but maybe none too for some). > > There might also be cases where we want some other conditional (like > combination > of cfgs) to gate. > > I am okay with gating existing ones under new cfgs, but requiring one in macro > invocation itself sounds bit excessive, and also doesn't look nice :) > > If we decide on actually requiring one, a better option might me for me to > implement a lint in klint to produce a warning that is suppressable if people > actually don't want to use cfgs. > In addition to KUnit, there is also a hardware-dependent IRQ test [1], that is normally configured to be skipped. Unless we decide, during review, that this kind of test is a Bad Idea.
This is likely independent of the KUnit selections, but I want us to just be aware of it in case it influences things here. [1] https://lore.kernel.org/[email protected] thanks, -- John Hubbard
