Message-ID: <CANiq72nX8UHAjz51skA9r6gKxc1BCUxkBsVRqoMrnsMNYjp_5g@mail.gmail.com>
Date: Mon, 26 Jan 2026 15:44:00 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Mark Brown <broonie@...nel.org>
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 Thu, Jan 22, 2026 at 1:13 PM Mark Brown <broonie@...nel.org> wrote:
>
> 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...

Ah, I see.

I would recommend the `rustfmtcheck` target, since it will not change
any files (i.e. it will work in a read-only srctree).

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

Hmm... If someone said that, then that is definitely wrong (and I and
others would see it sooner or later in CI).

The build log should be clean of warnings (all compiler, `rustdoc` and
Clippy ones).

Perhaps they were referring to "ignoring" as in using local
`#[allow(...)]` (or `expect`) attributes in the source file? That is
fine (where reasonable), since it is very localized (less than
file-scope, like the GCC/Clang diagnostic pragma but less verbose and
better integrated). It is also why we can be a bit more liberal in
enabling lints that may have a few false positives compared to the C
side.

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

Yeah, it is because it is invoked from the objtree, so it appears
there, not in the srctree.

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

Yeah, you would need the `--kconfig_add CONFIG_RUST=y` that David
mentioned, e.g. this seems to enable in the config the Rust ones for
me in a x86_64 host:

    ./tools/testing/kunit/kunit.py run --alltests --build_dir ../kunit
--arch x86_64 --kconfig_add CONFIG_RUST=y

The Rust ones get enabled even without `--alltests`.

I am not sure what the policies are around `all_tests.config` though,
e.g. the file says it is meant for UML, and I also see a recent revert
in that file due to unmet dependencies:

    ERROR:root:Not all Kconfig options selected in kunitconfig were in
the generated .config.
    This is probably due to unsatisfied dependencies.
    Missing: CONFIG_INIT_STACK_ALL_PATTERN=y

And indeed if I add `CONFIG_RUST=y` to the file, and run without a
Rust toolchain available, then it breaks similarly.

But if it is fine somehow to add `CONFIG_RUST=y` there even if people
do not have Rust available etc., then great.

David can probably say more about this.

Cheers,
Miguel

Powered by blists - more mailing lists