From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: Dmitrii Dolgov <9erthalion6@gmail.com>,
linux-perf-users@vger.kernel.org,
Namhyung Kim <namhyung@kernel.org>,
Ian Rogers <irogers@google.com>, Miguel Ojeda <ojeda@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
rust-for-linux <rust-for-linux@vger.kernel.org>,
Nathan Chancellor <nathan@kernel.org>,
Nicolas Schier <nsc@kernel.org>
Subject: Re: [PATCH v1] tools build: Fix feature test for rust compiler
Date: Wed, 11 Feb 2026 09:11:55 -0300 [thread overview]
Message-ID: <aYxyCypnmSuXSYYD@x1> (raw)
In-Reply-To: <CANiq72mFBaFm9QVotxeDB0TanKxQRko7ZFhuF-RHq-8WCemCTQ@mail.gmail.com>
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
next prev parent reply other threads:[~2026-02-11 12:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-11 9:58 [PATCH v1] tools build: Fix feature test for rust compiler Dmitrii Dolgov
2026-02-11 10:41 ` Miguel Ojeda
2026-02-11 12:11 ` Arnaldo Carvalho de Melo [this message]
2026-02-11 12:23 ` Arnaldo Carvalho de Melo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aYxyCypnmSuXSYYD@x1 \
--to=acme@kernel.org \
--cc=9erthalion6@gmail.com \
--cc=irogers@google.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=namhyung@kernel.org \
--cc=nathan@kernel.org \
--cc=nsc@kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox