Make every Rust KUnit test suite require the Kconfig option that controls
it, and let the `kunit_tests` macro apply the corresponding `#[cfg]`
attribute.

Most Rust KUnit suites currently combine a separate `#[cfg]` attribute with
`#[kunit_tests]`. The macro does not enforce this pattern, however, and the
Nova continuation suite currently has no dedicated test option.

Add a Nova Core KUnit option first and use it to guard the existing suite.
Then require a controlling Kconfig symbol in `kunit_tests` by moving the
guard into the macro. Update all callers and documentation as well.

Yury Norov (2):
  gpu: nova-core: add a KUnit test configuration option
  rust: kunit: move test configuration gating into macro

 Documentation/rust/testing.rst                | 11 ++++---
 drivers/gpu/nova-core/Kconfig                 | 12 ++++++++
 .../gpu/nova-core/gsp/cmdq/continuation.rs    |  2 +-
 rust/kernel/alloc/allocator.rs                |  3 +-
 rust/kernel/alloc/kvec.rs                     |  3 +-
 rust/kernel/bitfield.rs                       |  3 +-
 rust/kernel/bitmap.rs                         |  3 +-
 rust/kernel/kunit.rs                          |  3 +-
 rust/kernel/str.rs                            |  3 +-
 rust/kernel/sync/atomic/predefine.rs          |  3 +-
 rust/macros/kunit.rs                          | 30 +++++++++++++++++--
 rust/macros/lib.rs                            |  6 ++--
 12 files changed, 55 insertions(+), 27 deletions(-)

base-commit: aaa4e12f32b6552db1469a796312b25a0def7164
-- 
2.53.0

On Tue, Aug 18, 2026 at 5:23 PM Yury Norov <ynorov@nvidia.com> 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).

Cheers,
Miguel

On Tue Aug 18, 2026 at 9:44 PM BST, Miguel Ojeda wrote:
> On Tue, Aug 18, 2026 at 5:23 PM Yury Norov <ynorov@nvidia.com> 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.

Best,
Gary

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 <ynorov@nvidia.com> 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/20260808031120.363869-10-jhubbard@nvidia.com

thanks,
-- 
John Hubbard

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 <ynorov@nvidia.com> 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.

If there's a simple case of CONFIG_A && CONFIG_B, one can stack them up:

        #[cfg(CONFIG_THIS)]
        #[kunit_tests(rust_kernel_bitmap, CONFIG_THAT)]

If there's something more complicated... Let's wait for at least one
real test like that, and not speculate on non-existing cases.

> 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 :)

This series begins with "enforce", so it's not about being nice. The
generic kernel tries to save every single bit of memory and nanosecond
of runtime. That's a secret of Linux success IMO.

In the mother kernel every single test, performance benchmark or even
extra functionality is configurable, so that non-developer users don't
pay for the functionality they don't need. In Rust, before e74b7a3f5a
there was no way to throw the tests out. And even after that, we still
have such tests.

Let's stop being nice and make this bad habit explicitly impossible.

> 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.

This is not a coding style, it's a factual error. So it should be
caught at compile time as an explicit error.

Thanks,
Yury

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 <ynorov@nvidia.com> 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

On Wed, Aug 19, 2026 at 12:56 AM Yury Norov <ynorov@nvidia.com> wrote:
>
> If there's something more complicated... Let's wait for at least one
> real test like that, and not speculate on non-existing cases.

I asked because the issue is that this enforces a policy early on,
i.e. if a user happens to need it, then they will have to dive into
the implementation to change it or, likely, work around it or assume
they shouldn't do that.

In other words, there is a cost to enforce something too early on.

So it is a balance, depending on what we expect, which is why I asked
David about his experience here.

> This series begins with "enforce", so it's not about being nice. The
> generic kernel tries to save every single bit of memory and nanosecond
> of runtime. That's a secret of Linux success IMO.

It is great to save bits and nanoseconds, but KUnit is explicitly not
meant for production.

> pay for the functionality they don't need. In Rust, before e74b7a3f5a
> there was no way to throw the tests out. And even after that, we still
> have such tests.

False, you could disable KUnit (or make it `m`) -- which is what you
are supposed to do in production.

So, no, we were not bloating every Rust-enabled kernel out there with tests.

> This is not a coding style, it's a factual error. So it should be
> caught at compile time as an explicit error.

Klint and lints in general are not just for coding style.

And lints are also compile-time, and they can stop the build too.

Cheers,
Miguel