[PATCH 0/2] rust: kunit: enforce test configurability

[PATCH 0/2] rust: kunit: enforce test configurability

[Yury Norov]

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

[PATCH 1/2] gpu: nova-core: add a KUnit test configuration option

[Yury Norov]

The continuation-record KUnit tests are currently built whenever both
Nova Core and KUnit are enabled, providing no way to select the tests
independently.

Add CONFIG_NOVA_CORE_KUNIT_TEST and use it to guard the test suite.
Follow the usual KUnit convention of enabling the option through
CONFIG_KUNIT_ALL_TESTS.

Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: Yury Norov <ynorov@nvidia.com>
---
 drivers/gpu/nova-core/Kconfig                  | 12 ++++++++++++
 drivers/gpu/nova-core/gsp/cmdq/continuation.rs |  1 +
 2 files changed, 13 insertions(+)

diff --git a/drivers/gpu/nova-core/Kconfig b/drivers/gpu/nova-core/Kconfig
index f918f69e0599..d05c2c1d46d9 100644
--- a/drivers/gpu/nova-core/Kconfig
+++ b/drivers/gpu/nova-core/Kconfig
@@ -15,3 +15,15 @@ config NOVA_CORE
 	  This driver is work in progress and may not be functional.
 
 	  If M is selected, the module will be called nova-core.
+
+config NOVA_CORE_KUNIT_TEST
+	bool "KUnit tests for Nova Core" if !KUNIT_ALL_TESTS
+	depends on NOVA_CORE && KUNIT
+	default KUNIT_ALL_TESTS
+	help
+	  This option enables KUnit tests for internal components of the Nova
+	  Core driver. The tests currently do not require GPU hardware. These
+	  are only for development and testing, not for regular kernel use
+	  cases.
+
+	  If unsure, say N.
diff --git a/drivers/gpu/nova-core/gsp/cmdq/continuation.rs b/drivers/gpu/nova-core/gsp/cmdq/continuation.rs
index 05e904f18097..c0aa16c8fbf4 100644
--- a/drivers/gpu/nova-core/gsp/cmdq/continuation.rs
+++ b/drivers/gpu/nova-core/gsp/cmdq/continuation.rs
@@ -167,6 +167,7 @@ fn init_variable_payload(
     }
 }
 
+#[cfg(CONFIG_NOVA_CORE_KUNIT_TEST)]
 #[kunit_tests(nova_core_gsp_continuation)]
 mod tests {
     use super::*;
-- 
2.53.0

[PATCH 2/2] rust: kunit: move test configuration gating into macro

[Yury Norov]

KUnit test modules currently need a separate cfg attribute in addition to
the kunit_tests attribute. This makes every test suite repeat the same
two-attribute pattern.

Declaring a KUnit test without a preceding `#[cfg]` attribute is also
possible, causing it to be built whenever KUnit and its containing code are
enabled.

Require the controlling Kconfig symbol as the second kunit_tests argument
and have the macro emit the cfg attribute itself. Update all existing users
to the new form.

Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: Yury Norov <ynorov@nvidia.com>
---
 Documentation/rust/testing.rst                | 11 ++++---
 .../gpu/nova-core/gsp/cmdq/continuation.rs    |  3 +-
 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 ++--
 11 files changed, 43 insertions(+), 28 deletions(-)

diff --git a/Documentation/rust/testing.rst b/Documentation/rust/testing.rst
index e3943aceceb9..767b111afd41 100644
--- a/Documentation/rust/testing.rst
+++ b/Documentation/rust/testing.rst
@@ -138,9 +138,10 @@ these are also fairly similar to what you would expect from userspace, and they
 are also mapped to KUnit.
 
 These tests are introduced by the ``kunit_tests`` procedural macro, which takes
-the name of the test suite as an argument.
+the name of the test suite and its controlling Kconfig option as arguments. The
+Kconfig option is required, and the macro uses it to guard the test suite.
 
-Each test suite should be guarded by a Kconfig option in
+Each test suite should have a Kconfig option, typically in
 ``rust/kernel/Kconfig.test``.
 
 For instance, assume we want to test the function ``f`` from the documentation
@@ -148,8 +149,7 @@ tests section. We could write, in the same file where we have our function:
 
 .. code-block:: rust
 
-	#[cfg(CONFIG_RUST_MYMOD_KUNIT_TEST)]
-	#[kunit_tests(rust_kernel_mymod)]
+	#[kunit_tests(rust_kernel_mymod, CONFIG_RUST_MYMOD_KUNIT_TEST)]
 	mod tests {
 	    use super::*;
 
@@ -177,8 +177,7 @@ the unit type ``()``) or ``Result`` (i.e. any ``Result<T, E>``). For instance:
 
 .. code-block:: rust
 
-	#[cfg(CONFIG_RUST_MYMOD_KUNIT_TEST)]
-	#[kunit_tests(rust_kernel_mymod)]
+	#[kunit_tests(rust_kernel_mymod, CONFIG_RUST_MYMOD_KUNIT_TEST)]
 	mod tests {
 	    use super::*;
 
diff --git a/drivers/gpu/nova-core/gsp/cmdq/continuation.rs b/drivers/gpu/nova-core/gsp/cmdq/continuation.rs
index c0aa16c8fbf4..2e4b21f2002f 100644
--- a/drivers/gpu/nova-core/gsp/cmdq/continuation.rs
+++ b/drivers/gpu/nova-core/gsp/cmdq/continuation.rs
@@ -167,8 +167,7 @@ fn init_variable_payload(
     }
 }
 
-#[cfg(CONFIG_NOVA_CORE_KUNIT_TEST)]
-#[kunit_tests(nova_core_gsp_continuation)]
+#[kunit_tests(nova_core_gsp_continuation, CONFIG_NOVA_CORE_KUNIT_TEST)]
 mod tests {
     use super::*;
 
diff --git a/rust/kernel/alloc/allocator.rs b/rust/kernel/alloc/allocator.rs
index cd4203f27aed..b2c235801a3f 100644
--- a/rust/kernel/alloc/allocator.rs
+++ b/rust/kernel/alloc/allocator.rs
@@ -265,8 +265,7 @@ unsafe fn realloc(
     }
 }
 
-#[cfg(CONFIG_RUST_ALLOCATOR_KUNIT_TEST)]
-#[macros::kunit_tests(rust_allocator)]
+#[macros::kunit_tests(rust_allocator, CONFIG_RUST_ALLOCATOR_KUNIT_TEST)]
 mod tests {
     use super::*;
     use core::mem::MaybeUninit;
diff --git a/rust/kernel/alloc/kvec.rs b/rust/kernel/alloc/kvec.rs
index f7af62835aa8..4b77425950d3 100644
--- a/rust/kernel/alloc/kvec.rs
+++ b/rust/kernel/alloc/kvec.rs
@@ -1508,8 +1508,7 @@ fn drop(&mut self) {
     }
 }
 
-#[cfg(CONFIG_RUST_KVEC_KUNIT_TEST)]
-#[macros::kunit_tests(rust_kvec)]
+#[macros::kunit_tests(rust_kvec, CONFIG_RUST_KVEC_KUNIT_TEST)]
 mod tests {
     use super::*;
     use crate::prelude::*;
diff --git a/rust/kernel/bitfield.rs b/rust/kernel/bitfield.rs
index 35ede53f2b8e..8b329b6e4f8d 100644
--- a/rust/kernel/bitfield.rs
+++ b/rust/kernel/bitfield.rs
@@ -548,8 +548,7 @@ fn fmt(&self, f: &mut ::kernel::fmt::Formatter<'_>) -> ::kernel::fmt::Result {
     };
 }
 
-#[cfg(CONFIG_RUST_BITFIELD_KUNIT_TEST)]
-#[::kernel::macros::kunit_tests(rust_kernel_bitfield)]
+#[::kernel::macros::kunit_tests(rust_kernel_bitfield, CONFIG_RUST_BITFIELD_KUNIT_TEST)]
 mod tests {
     use core::convert::TryFrom;
 
diff --git a/rust/kernel/bitmap.rs b/rust/kernel/bitmap.rs
index b27e0ec80d64..c4195e00d895 100644
--- a/rust/kernel/bitmap.rs
+++ b/rust/kernel/bitmap.rs
@@ -499,8 +499,7 @@ pub fn next_zero_bit(&self, start: usize) -> Option<usize> {
     }
 }
 
-#[cfg(CONFIG_RUST_BITMAP_KUNIT_TEST)]
-#[macros::kunit_tests(rust_kernel_bitmap)]
+#[macros::kunit_tests(rust_kernel_bitmap, CONFIG_RUST_BITMAP_KUNIT_TEST)]
 mod tests {
     use super::*;
     use kernel::alloc::flags::GFP_KERNEL;
diff --git a/rust/kernel/kunit.rs b/rust/kernel/kunit.rs
index 91eaff8c186a..52f2ccbfba49 100644
--- a/rust/kernel/kunit.rs
+++ b/rust/kernel/kunit.rs
@@ -330,8 +330,7 @@ pub fn in_kunit_test() -> bool {
     !unsafe { bindings::kunit_get_current_test() }.is_null()
 }
 
-#[cfg(CONFIG_RUST_KUNIT_SELFTEST)]
-#[kunit_tests(rust_kernel_kunit)]
+#[kunit_tests(rust_kernel_kunit, CONFIG_RUST_KUNIT_SELFTEST)]
 mod tests {
     use super::*;
 
diff --git a/rust/kernel/str.rs b/rust/kernel/str.rs
index b3caa9a1c898..404418504c13 100644
--- a/rust/kernel/str.rs
+++ b/rust/kernel/str.rs
@@ -428,8 +428,7 @@ macro_rules! c_str {
     }};
 }
 
-#[cfg(CONFIG_RUST_STR_KUNIT_TEST)]
-#[kunit_tests(rust_kernel_str)]
+#[kunit_tests(rust_kernel_str, CONFIG_RUST_STR_KUNIT_TEST)]
 mod tests {
     use super::*;
 
diff --git a/rust/kernel/sync/atomic/predefine.rs b/rust/kernel/sync/atomic/predefine.rs
index 3d63f40791fa..e92194b37de8 100644
--- a/rust/kernel/sync/atomic/predefine.rs
+++ b/rust/kernel/sync/atomic/predefine.rs
@@ -152,8 +152,7 @@ fn rhs_into_delta(rhs: usize) -> isize_atomic_repr {
     }
 }
 
-#[cfg(CONFIG_RUST_ATOMICS_KUNIT_TEST)]
-#[macros::kunit_tests(rust_atomics)]
+#[macros::kunit_tests(rust_atomics, CONFIG_RUST_ATOMICS_KUNIT_TEST)]
 mod tests {
     use super::super::*;
 
diff --git a/rust/macros/kunit.rs b/rust/macros/kunit.rs
index ae20ed6768f1..7c7ba30f58c0 100644
--- a/rust/macros/kunit.rs
+++ b/rust/macros/kunit.rs
@@ -13,6 +13,10 @@
     ToTokens, //
 };
 use syn::{
+    parse::{
+        Parse,
+        ParseStream, //
+    },
     parse_quote,
     Error,
     Ident,
@@ -20,9 +24,28 @@
     ItemMod,
     LitCStr,
     Result, //
+    Token,
 };
 
-pub(crate) fn kunit_tests(test_suite: Ident, mut module: ItemMod) -> Result<TokenStream> {
+pub(crate) struct KunitTestArgs {
+    test_suite: Ident,
+    config: Ident,
+}
+
+impl Parse for KunitTestArgs {
+    fn parse(input: ParseStream<'_>) -> Result<Self> {
+        let test_suite = input.parse()?;
+        input.parse::<Token![,]>()?;
+        let config = input.parse()?;
+
+        Ok(Self { test_suite, config })
+    }
+}
+
+pub(crate) fn kunit_tests(
+    KunitTestArgs { test_suite, config }: KunitTestArgs,
+    mut module: ItemMod,
+) -> Result<TokenStream> {
     if test_suite.to_string().len() > 255 {
         return Err(Error::new_spanned(
             test_suite,
@@ -34,7 +57,7 @@ pub(crate) fn kunit_tests(test_suite: Ident, mut module: ItemMod) -> Result<Toke
     let Some((module_brace, module_items)) = module.content.take() else {
         Err(Error::new_spanned(
             module,
-            "`#[kunit_tests(test_name)]` attribute should only be applied to inline modules",
+            "`#[kunit_tests(test_name, CONFIG_KUNIT_TEST)]` attribute should only be applied to inline modules",
         ))?
     };
 
@@ -42,6 +65,7 @@ pub(crate) fn kunit_tests(test_suite: Ident, mut module: ItemMod) -> Result<Toke
     module
         .attrs
         .insert(0, parse_quote!(#[cfg(CONFIG_KUNIT="y")]));
+    module.attrs.insert(0, parse_quote!(#[cfg(#config)]));
 
     let mut processed_items = Vec::new();
     let mut test_cases = Vec::new();
@@ -51,7 +75,7 @@ pub(crate) fn kunit_tests(test_suite: Ident, mut module: ItemMod) -> Result<Toke
     // The code generated for the following test module:
     //
     // ```
-    // #[kunit_tests(kunit_test_suit_name)]
+    // #[kunit_tests(kunit_test_suite_name, CONFIG_KUNIT_TEST)]
     // mod tests {
     //     #[test]
     //     fn foo() {
diff --git a/rust/macros/lib.rs b/rust/macros/lib.rs
index 4a48fabbc268..a660296d5dbd 100644
--- a/rust/macros/lib.rs
+++ b/rust/macros/lib.rs
@@ -464,14 +464,14 @@ pub fn paste(input: TokenStream) -> TokenStream {
 
 /// Registers a KUnit test suite and its test cases using a user-space like syntax.
 ///
-/// This macro should be used on modules. If `CONFIG_KUNIT` (in `.config`) is `n`, the target module
-/// is ignored.
+/// This macro should be used on modules. The second argument is the Kconfig symbol that controls
+/// the test suite. If it or `CONFIG_KUNIT` (in `.config`) is `n`, the target module is ignored.
 ///
 /// # Examples
 ///
 /// ```ignore
 /// # use kernel::prelude::*;
-/// #[kunit_tests(kunit_test_suit_name)]
+/// #[kunit_tests(kunit_test_suite_name, CONFIG_KUNIT_TEST)]
 /// mod tests {
 ///     #[test]
 ///     fn foo() {
-- 
2.53.0

Re: [PATCH 0/2] rust: kunit: enforce test configurability

[Miguel Ojeda]

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

Re: [PATCH 0/2] rust: kunit: enforce test configurability

[Gary Guo]

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

Re: [PATCH 0/2] rust: kunit: enforce test configurability

[Yury Norov]

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

Re: [PATCH 0/2] rust: kunit: enforce test configurability

[Miguel Ojeda]

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

Re: [PATCH 0/2] rust: kunit: enforce test configurability

[Gary Guo]

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

Re: [PATCH 0/2] rust: kunit: enforce test configurability

[John Hubbard]

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