Re: [PATCH] kbuild: rust: support stabilized flag `-Cprofile-sample-use` for Rust >= 1.100

[Nathan Chancellor <nathan@kernel.org>]

On Fri, Nov 06, 2026 at 12:04:08PM +0100, Miguel Ojeda wrote:
> On Fri, Nov 6, 2026 at 11:45 AM Alice Ryhl <aliceryhl@google.com> wrote:
> >
> > Could we check for `-Cprofile-sample-use` directly using `rustc-option`
> > instead of checking the rustc version (e.g. testing
> > `-Cprofile-sample-use=/dev/null` or using `$(call rustc-option,...)`)?
> > That way toolchains that cherry-pick the stabilization (or older 1.100
> > nightlies from before the flag was stabilized) are also handled
> > properly.
> 
> It is definitely an option, as usual, but this file uses the version
> elsewhere, and we have preferred so far the version one where
> possible, because it is way simpler and spawns fewer processes
> (especially so in newer Make), which Kbuild has usually appreciated.

Yeah, there is always a fine line between deciding whether or not to do
a dynamic versus version check. Obviously the cost of querying the
compiler is not that high in the grand scheme of the total build time,
so I don't think we should be scared of doing dynamic tests, However, I
do think doing plain version checks is simpler to support, especially
since it makes cleaning up these changes as the minimum version is
bumped.

> Regarding old nightlies, those are not supported by upstream nor by
> us, and we intentionally never attempted to make flags work for
> particular binaries out there. I think the fact that we support even
> nightlies from Rust is already quite a success :)

Yeah, for clang, we have done our best to support prerelease versions
but once the toolchain stabilizes, we don't care about those old
versions. I generally try to do version checks against the stable
version (i.e., x.1.0, instead of x.0.0) to avoid breaking compiler
bisects but I guess Rust doesn't have such a scheme? That is the only
area where I feel friction with version checks.

> Same for custom `rustc` forks, if you mean "cherry-picking the
> stabilization". We can't really test those, and if someone really
> needs that properly working and can make a case, then we would need to
> take a look at all the version tests we do (and not just for Rust).
> Perhaps some folks only customize 1 or 2 flags and thus only care
> about those working, but we wouldn't know which ones.

To be honest, I would avoid supporting franken-toolchains if you have
the option not to. Presumably if a vendor has customized or vendored
their toolchain, they are likely working with a downstream kernel as
well, in which case they can just adjust the check in their tree as
needed. You could obviously deal with exceptions on a case-by-case basis
but reasoning about all the different options and their first supported
version is hard enough as it is.

-- 
Cheers,
Nathan