linux-kernel - Re: [PATCH v1] tools build: Fix feature test for rust compiler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aYxyCypnmSuXSYYD@x1>
Date: Wed, 11 Feb 2026 09:11:55 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: Dmitrii Dolgov <9erthalion6@...il.com>,
	linux-perf-users@...r.kernel.org,
	Namhyung Kim <namhyung@...nel.org>, Ian Rogers <irogers@...gle.com>,
	Miguel Ojeda <ojeda@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
	rust-for-linux <rust-for-linux@...r.kernel.org>,
	Nathan Chancellor <nathan@...nel.org>,
	Nicolas Schier <nsc@...nel.org>
Subject: Re: [PATCH v1] tools build: Fix feature test for rust compiler

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@...il.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@...il.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@...lbx linux]$ find tools -name "*.rs"
tools/build/feature/test-rust.rs
tools/perf/tests/workloads/code_with_type.rs
⬢ [acme@...lbx 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