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