[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANiq72=1ipov2pV9pSQwGh9WMA4NvQRV_cBCO0hhChVg=c-Njw@mail.gmail.com>
Date: Tue, 2 Dec 2025 00:13:33 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Yury Norov <yury.norov@...il.com>
Cc: Miguel Ojeda <ojeda@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>, Burak Emir <bqe@...gle.com>,
Alex Gaynor <alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>,
Gary Guo <gary@...yguo.net>, Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Benno Lossin <lossin@...nel.org>, Andreas Hindborg <a.hindborg@...nel.org>,
Trevor Gross <tmgross@...ch.edu>, Danilo Krummrich <dakr@...nel.org>, rust-for-linux@...r.kernel.org,
linux-kernel@...r.kernel.org, patches@...ts.linux.dev
Subject: Re: [PATCH] rust: id_pool: fix example
On Mon, Dec 1, 2025 at 8:29 PM Yury Norov <yury.norov@...il.com> wrote:
>
> Thanks Miguel,
>
> I applied this, but the fact that you've sent a second fix to
> documentation that actually is a build fix, raises the questions.
>
> Because Rust documentation bears compilable chunks of code, I think
> we need to enable rustdoc tests target by default, so that developers
> will not send broken tests.
You're welcome!
This one is a Kconfig in the normal build, i.e.
`CONFIG_RUST_KERNEL_DOCTESTS` (it is true that the other patch was for
a different target).
If you mean enabling that by Kconfig default, then I don't think we
can do that -- KUnit on its own (which this uses) is not meant for
normal builds. Perhaps we could have something that just checks the
build, but people should really run the doctests anyway, since they
typically contain `assert!`s and so on that can be wrong.
If you mean enabling it in Intel's kernel test robot, then I think
they do it (or at least I told them about it long ago). But maybe
something is missing.
In our P entry in `MAINTAINERS` ("Subsystem Profile document") we ask
people to run them among other things, so I would perhaps suggest
having something like that too (or linking to ours if you prefer):
https://rust-for-linux.com/contributing#submit-checklist-addendum
Of course new contributors will miss that initially, but actually
people find the doctests quite useful, so generally people get to run
them. At the end of the day, maintainers should test these too before
applying and otherwise someone will notice sooner or later.
I hope that helps!
Cheers,
Miguel
Powered by blists - more mailing lists