Currently a dummy rust code is compiled to detect if the rust feature
could be enabled. It turns out that in this case rust emits a dependency
file without any external references:

    /perf/feature/test-rust.d: test-rust.rs

    /perf/feature/test-rust.bin: test-rust.rs

    test-rust.rs:

This can lead to a situation, when rustc was removed after a successful build,
but the build process still thinks it's there and the feature is enabled on
subsequent runs.

Instead simply check the compiler presence to detect the feature, as
suggested by Arnaldo Carvalho de Melo. This way no actual test-rust.bin
will be created, meaning the feature check will not be cached and always
performed. That's exactly what we want, and the overhead of doing this
every time is minimal.

Tested with multiple rounds of install/remove of the rust package.

Signed-off-by: Dmitrii Dolgov <9erthalion6@gmail.com>
---
 tools/build/feature/Makefile     | 10 ++++++----
 tools/build/feature/test-rust.rs |  4 ----
 2 files changed, 6 insertions(+), 8 deletions(-)
 delete mode 100644 tools/build/feature/test-rust.rs

diff --git a/tools/build/feature/Makefile b/tools/build/feature/Makefile
index e959caa7f1c..698e89da015 100644
--- a/tools/build/feature/Makefile
+++ b/tools/build/feature/Makefile
@@ -113,9 +113,6 @@ __BUILD = $(CC) $(CFLAGS) -MD -Wall -Werror -o $@ $(patsubst %.bin,%.c,$(@F)) $(
 __BUILDXX = $(CXX) $(CXXFLAGS) -MD -Wall -Werror -o $@ $(patsubst %.bin,%.cpp,$(@F)) $(LDFLAGS)
   BUILDXX = $(__BUILDXX) > $(@:.bin=.make.output) 2>&1
 
-__BUILDRS = $(RUSTC) $(RUSTC_FLAGS) --emit=dep-info=$(patsubst %.bin,%.d,$(@F)),link -o $@ $(patsubst %.bin,%.rs,$(@F))
-  BUILDRS = $(__BUILDRS) > $(@:.bin=.make.output) 2>&1
-
 ###############################
 
 $(OUTPUT)test-all.bin:
@@ -393,8 +390,13 @@ $(OUTPUT)test-bpftool-skeletons.bin:
 	$(SYSTEM_BPFTOOL) version | grep '^features:.*skeletons' \
 		> $(@:.bin=.make.output) 2>&1
 
+# Testing Rust is special: we don't compile anything, it's enough to check the
+# compiler presence. Compiling a test code for this purposes is problematic,
+# because Rust will emit a depedency file without any external references,
+# meaning that if rustc will be removed the build process will still think it's
+# there.
 $(OUTPUT)test-rust.bin:
-	$(BUILDRS) > $(@:.bin=.make.output) 2>&1
+	$(RUSTC) --version > /dev/null 2>&1
 
 ###############################
 
diff --git a/tools/build/feature/test-rust.rs b/tools/build/feature/test-rust.rs
deleted file mode 100644
index f2fc91cc4f6..00000000000
--- a/tools/build/feature/test-rust.rs
+++ /dev/null
@@ -1,4 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-fn main() {
-    println!("hi")
-}

base-commit: 5d1ab659fb93eed85d6d8b2937013360157032f4
-- 
2.52.0

On Wed, Feb 11, 2026 at 10:58:01AM +0100, Dmitrii Dolgov wrote:
> Currently a dummy rust code is compiled to detect if the rust feature
> could be enabled. It turns out that in this case rust emits a dependency
> file without any external references:
> 
>     /perf/feature/test-rust.d: test-rust.rs
> 
>     /perf/feature/test-rust.bin: test-rust.rs
> 
>     test-rust.rs:
> 
> This can lead to a situation, when rustc was removed after a successful build,
> but the build process still thinks it's there and the feature is enabled on
> subsequent runs.
> 
> Instead simply check the compiler presence to detect the feature, as
> suggested by Arnaldo Carvalho de Melo. This way no actual test-rust.bin
> will be created, meaning the feature check will not be cached and always
> performed. That's exactly what we want, and the overhead of doing this
> every time is minimal.
> 
> Tested with multiple rounds of install/remove of the rust package.

Yeah, seems to work, applied.

- Arnaldo

On Wed, Feb 11, 2026 at 10:58 AM Dmitrii Dolgov <9erthalion6@gmail.com> wrote:
>
> Currently a dummy rust code is compiled to detect if the rust feature
> could be enabled. It turns out that in this case rust emits a dependency
> file without any external references:
>
>     /perf/feature/test-rust.d: test-rust.rs
>
>     /perf/feature/test-rust.bin: test-rust.rs
>
>     test-rust.rs:
>
> This can lead to a situation, when rustc was removed after a successful build,
> but the build process still thinks it's there and the feature is enabled on
> subsequent runs.
>
> Instead simply check the compiler presence to detect the feature, as
> suggested by Arnaldo Carvalho de Melo. This way no actual test-rust.bin
> will be created, meaning the feature check will not be cached and always
> performed. That's exactly what we want, and the overhead of doing this
> every time is minimal.
>
> Tested with multiple rounds of install/remove of the rust package.
>
> Signed-off-by: Dmitrii Dolgov <9erthalion6@gmail.com>

Not sure if Kbuild covers this given it is `tools/`, but just in case
given the `MAINTAINERS` file, Cc'ing them, as well as rust-for-linux
since we try to use it as an index of Rust-related things there within
the kernel.

I hope that helps.

Cheers,
Miguel

On Wed, Feb 11, 2026 at 11:41:06AM +0100, Miguel Ojeda wrote:
> On Wed, Feb 11, 2026 at 10:58 AM Dmitrii Dolgov <9erthalion6@gmail.com> wrote:
> > Currently a dummy rust code is compiled to detect if the rust feature
> > could be enabled. It turns out that in this case rust emits a dependency
> > file without any external references:

> >     /perf/feature/test-rust.d: test-rust.rs

> >     /perf/feature/test-rust.bin: test-rust.rs

> >     test-rust.rs:

> > This can lead to a situation, when rustc was removed after a successful build,
> > but the build process still thinks it's there and the feature is enabled on
> > subsequent runs.

> > Instead simply check the compiler presence to detect the feature, as
> > suggested by Arnaldo Carvalho de Melo. This way no actual test-rust.bin
> > will be created, meaning the feature check will not be cached and always
> > performed. That's exactly what we want, and the overhead of doing this
> > every time is minimal.

> > Tested with multiple rounds of install/remove of the rust package.

> > Signed-off-by: Dmitrii Dolgov <9erthalion6@gmail.com>
 
> Not sure if Kbuild covers this given it is `tools/`, but just in case
> given the `MAINTAINERS` file, Cc'ing them, as well as rust-for-linux
> since we try to use it as an index of Rust-related things there within
> the kernel.

Right, this started with Dmitrii wanting to help with data-type
profiling in Rust, as Namhyung mentioned in his LPC talk that there was
work to be done to support other languages.

Since he had tested it and it seemed to work, I suggested he turned his
recent experience into a 'perf test' for data-type profiling on a Rust
workload and this series came out of that.

This has even caught a regression already, namely:

  64ea7a4620008652 ("perf annotate: Fix register usage in data type profiling")

https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/commit/?h=64ea7a4620008652

Now it is the first, AFAIK, experience with rust in tools/, as this
shows:

⬢ [acme@toolbx linux]$ find tools -name "*.rs"
tools/build/feature/test-rust.rs
tools/perf/tests/workloads/code_with_type.rs
⬢ [acme@toolbx linux]$

With the above patch we'll be left with just
tools/perf/tests/workloads/code_with_type.rs, that is linked into perf,
if rust is available, and we need to figure out to reduce the impact in
the size of perf, which is noticeable, but as it is not a strict
requirement, we can have this addressed in later work.

Hopefully this helps pave the way for more Rust tooling to flourish in
tools/.

- Arnaldo