On Tue Aug 18, 2026 at 11:56 PM BST, Yury Norov wrote:
> On Tue, Aug 18, 2026 at 10:23:51PM +0100, 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.
>
> But not a single current case. All the current tests are flat and
> simple: every test has it's unique gate config. Do we need a more
> complicated scheme? I doubt that.
A common case in Rust crates is when some shared code exists when either of two
features are enabled, do
#[cfg(any(feature_a, feature_b))]
sure, with Kconfig you can add new config and select based on that.
I see this as an issue with composition. `#[cfg]` and `#[kunit_tests]` are two
orthogonal attributes so one shouldn't (and shouldn't need to) be absorbed into
another.
For a crate, one might want to have multiple kunit test suites in a shared
module. For that, you currently can do
#[cfg(CONFIG_THIS)]
mod tests;
and have `#[kunit_tests]` insides the tests module freely. Your design would not
allow this (or would require a always-enabled feature to be passed in to appease
the macro). Also, for a leaf driver crate, all `#[kunit_tests]` would likely
share a single config, so there's repetition as well.
There's also an issue with doc tests. Unlike explicit kunit tests, the test
suite is generated and you don't have to stick your attributes. Currently we
have all abstractions in a single kernel crate, but when the new build system
for Rust lands, we would have each subsystem being their own crate, and
obviously we would need a mechanism to control when doc tests are executed.
A more reasonable approach IMO would be to specify provide a global gate to all
kunit tests within a crate. So, e.g. for Nova core, just add
pass the Kconfig CONFIG_NOVA_CORE_KUNIT_TEST name to makefile and it'll gate all
kunit tests within the crate.
Best,
Gary
