Message-ID: <CANiq72kT9ThJcr5W0OhBmbwKZCpULjUehNjijTt8W09yB0CxSg@mail.gmail.com>
Date: Wed, 21 Jan 2026 19:55:39 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Mark Brown <broonie@...nel.org>, David Gow <davidgow@...gle.com>
Cc: Tamir Duberstein <tamird@...il.com>, Andreas Hindborg <a.hindborg@...nel.org>, 
	Jens Axboe <axboe@...nel.dk>, Miguel Ojeda <ojeda@...nel.org>, 
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, 
	Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: build failure after merge of the block tree

On Wed, Jan 21, 2026 at 3:56 PM Mark Brown <broonie@...nel.org> wrote:
>
> I'll update my notes to rustfmtcheck, I presume that exits with an error
> if it fails?  I'm not actually doing any of this Rust stuff yet, the
> builds that are done are just what happens when all*config sees a Rust
> toolchain installed.  I've got a small pile of things I'm going through
> one at a time.

Yeah, the `rustfmtcheck` target just returns non-zero (and the diff)
if formatting is required.

> We do really want things to respect O=, all the -next builds are using
> that, so if anything shows up in the source tree that's a concern.  I am
> bodging that for the kselftest build at the minute but it's not great.

Not sure what you mean about `O=`. Using `O=` is supported (both for
the subdir and external dir cases which are slightly different in the
build system). Modulo bugs, of course.

If you mean to ask whether `rustfmt` creates files: no, it replaces
in-place, i.e. by `git status` I meant you would see modified files,
not new ones.

> That is not going to be usable if it fails -Werror builds, Rust is only
> enabled by the all*config configurations and they turn on -Werror
> through the same process that they turn on Rust.  We really need -Werror
> to pass.  I can set CLIPPY=1 for other configs then if they enable Rust
> they'll need to pass cleanly but then it'll just explode when turned on
> if there's lots of warnings which doesn't seem like it'll help Rust
> adoption.  If we were starting from a point where the build was clean
> then it'd be more viable.

I am not sure I understand. `CLIPPY=1` is intended to be clean, and
over time I have sent patches to trees that break that (same for
`rustfmt` and `rustdoc`).

Things should already be generally clean modulo small bits that appear
from time to time. I just ran an `allmodconfig` in next-20260121 with
Rust 1.92.0 and I saw one `rustfmt` issue, one `rustdoc` and one
`CLIPPY=1` one -- I just sent patches for all (a couple appeared
today, the last one is in a driver I was not enabling in my regular CI
runs so I missed that one but it is nevertheless new in v6.19).

I have put you in Cc so that you can see the usual things that you may
spot when merging trees if the maintainers didn't do it.

That is why if you could enforce this in linux-next it would help a
lot, instead of fixing trees after the fact like in the emails above.
Things will still slip through, of course, depending on
configs/arch/... etc., but it would definitely help catch most of it.

i.e. what I am saying is that trees ideally should not be merged at
all if they trigger `CLIPPY=1` warnings (of course, exceptions can be
made when needed, e.g. on an emergency).

> I should be able to run rust-analyzer to verify that it doesn't error at
> least, it looks like rust-analyzer unconditionally outputs into the
> current source tree, but it is just one specific file so it's less of an
> issue than random cruft.

No, it outputs to `O=` -- if that is not working for you, please let me know.

i.e. that should not be a problem even for e.g. read-only srctrees.

> Running rusttest is a bit weird in that it requires a kernel config but
> seems to work fine so I can do that, I was already planning to run KUnit:

We used the `rusttest` target more in the past, before I made the
KUnit integration of the doctests, but it really doesn't do much
nowadays and carries a fair bit of complexity on the build system. My
current thinking is to migrate those tests and then just make it no-op
until we find a better use case if any for the target name. So it
isn't critical if you don't run it.

Now, you mention KUnit, and that is very interesting!

The overwhelming majority of our tests are all in fact KUnit-based,
e.g. these are our doctests (i.e. examples that are built and ran as
tests):

    [  2.714912] # rust_doctests_kernel: pass:283 fail:0 skip:0 total:283

but we also have a few other suites that come from `#[test]`s
("normal" unit tests), e.g.:

     [  2.260774] # rust_atomics: pass:6 fail:0 skip:0 total:6

So, do you mean you plan to run them under QEMU for x86_64 or arm64 or
similar? That would be amazing for us! I didn't know you planned to do
runtime tests.

For x86_64 and arm64 things should work fine and it would be great to
enforce it in linux-next already (I check the KUnit results in several
trees, including stable/LTSs).

Now, if you mean UML to run them, that is still best-effort with Rust,
and it may or may not be completely clean at certain moments (Cc'ing
David, who has been driving that and done a ton of work there).

Cheers,
Miguel

Powered by blists - more mailing lists