Message-ID: <8cc01720-427d-4cec-b4d0-721b22c47552@sirena.org.uk>
Date: Thu, 22 Jan 2026 12:13:11 +0000
From: Mark Brown <broonie@...nel.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: David Gow <davidgow@...gle.com>, 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 07:55:39PM +0100, Miguel Ojeda wrote:
> On Wed, Jan 21, 2026 at 3:56 PM Mark Brown <broonie@...nel.org> wrote:

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

I was asking because you were mentioning checking git status and since
we are doing out of tree builds there should be nothing changing in the
source at all.  I think with the way we get trees to the build machine
it won't make a difference in the end though if no new files are
created so it'll actually be fine...

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

I've been seeing people saying "oh, just ignore the warnings" on the Tyr
issues so it wasn't clear to me that people were expecting things to be
clean.  If things are generally clean that's fine, and I can hold the
trees back in -next if they introduce errors like I would with anything
else that does that.

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

Right, and there's the issues with things only being built in which you
said you expected to be resolved soonish.  Let's see how it goes - I'll
wait until the build is clean before enabling things (that had been my
intention with building at all, I didn't really register that all*config
would turn on Rust when the toolchains).

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

Ah, great.  I got confused by the make rule just having a plain
redirect to rust-project.json with no irectory prefix.

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

OK, if the plan is more to phase it out for the time being then I'll
just skip 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.

My current initial plan is:

    ./tools/testing/kunit/kunit.py run --alltests --build_dir ../kunit --arch arm64

but I didn't actually turn that on, I want to write a wrapper that
reports any failures in a mail ready format.  I'm not seeing rust in
tools/testing/kunit/configs/all_tests.config though so Rust wouldn't get
enabled?

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

I can't use UML as my build host is arm64 and UML is x86_64 only so that
won't be an issue for me.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists