From: Yury Norov <ynorov@nvidia.com>
To: Gary Guo <gary@garyguo.net>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
David Gow <david@davidgow.net>, Miguel Ojeda <ojeda@kernel.org>,
Danilo Krummrich <dakr@kernel.org>,
Alexandre Courbot <acourbot@nvidia.com>,
rust-for-linux@vger.kernel.org, nova-gpu@lists.linux.dev,
John Hubbard <jhubbard@nvidia.com>,
Alice Ryhl <aliceryhl@google.com>,
Burak Emir <burak.emir@gmail.com>,
Brendan Higgins <brendan.higgins@linux.dev>,
Rae Moar <raemoar63@gmail.com>, Yury Norov <yury.norov@gmail.com>,
linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] rust: kunit: enforce test configurability
Date: Tue, 18 Aug 2026 18:56:30 -0400 [thread overview]
Message-ID: <aoTjHtiSHJAuDQ7B@yury> (raw)
In-Reply-To: <DKSDWO1NQKF3.25QCXPPUM27J4@garyguo.net>
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
next prev parent reply other threads:[~2026-08-18 22:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-18 15:23 [PATCH 0/2] rust: kunit: enforce test configurability Yury Norov
2026-08-18 15:23 ` [PATCH 1/2] gpu: nova-core: add a KUnit test configuration option Yury Norov
2026-08-18 15:23 ` [PATCH 2/2] rust: kunit: move test configuration gating into macro Yury Norov
2026-08-18 20:44 ` [PATCH 0/2] rust: kunit: enforce test configurability Miguel Ojeda
2026-08-18 21:23 ` Gary Guo
2026-08-18 22:56 ` Yury Norov [this message]
2026-08-18 23:49 ` Miguel Ojeda
2026-08-19 0:41 ` Gary Guo
2026-08-19 0:10 ` John Hubbard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aoTjHtiSHJAuDQ7B@yury \
--to=ynorov@nvidia.com \
--cc=acourbot@nvidia.com \
--cc=aliceryhl@google.com \
--cc=brendan.higgins@linux.dev \
--cc=burak.emir@gmail.com \
--cc=dakr@kernel.org \
--cc=david@davidgow.net \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=kunit-dev@googlegroups.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=nova-gpu@lists.linux.dev \
--cc=ojeda@kernel.org \
--cc=raemoar63@gmail.com \
--cc=rust-for-linux@vger.kernel.org \
--cc=yury.norov@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox