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

[John Hubbard <jhubbard@nvidia.com>]

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