Re: [PATCH 0/2] rust: kernel: add cfg_select! and use it for config-based selection

[Miguel Ojeda]

On Mon, Jun 29, 2026 at 5:52 AM Nika Krasnova <ni...@nikableh.moe> wrote:
>
> The standard library gained core::cfg_select! for exactly this (stable
> since Rust 1.95.0): one macro that emits the first arm whose cfg
> predicate holds. The kernel's MSRV is 1.85.0, so it is not yet
> available.

We can use unstable features before the are stable -- from a quick
look, `cfg_match!` (its previous name) has been there since Rust
1.74.0, with the new name since Rust 1.89.0, and with the latest
behavior change since Rust 1.91.0. (I didn't take a close look, just
going by the tracking issue).

When something like this happens, we typically want to consider
whether it makes sense to reuse (internally) the original (if it makes
sense -- probably not here) or "forward"/re-export to the upstream one
when behavior matches.

For instance, instead of waiting for the MSRV bump, could we already
use the upstream one since Rust 1.91.0? That means that we are already
sure we are using the upstream one as-is.

Or is there a reason to avoid that?

Thanks!

Cheers,
Miguel

[Miguel Ojeda]

On Mon, Jun 29, 2026 at 11:38 AM Miguel Ojeda
<miguel.oje...@gmail.com> wrote:
>
> For instance, instead of waiting for the MSRV bump, could we already
> use the upstream one since Rust 1.91.0? That means that we are already
> sure we are using the upstream one as-is.

By the way, this also applies for the docs -- we will eventually use
upstream's, and thus it is best to try to match the docs too.

It also means we probably want to put this into `std_vendor.rs` if we
are going to copy-paste the docs verbatim, even if it is not code as
such (no implementation upstream since it is a built-in).

E.g. for a similar case, please see:

https://lore.kernel.org/rust-for-linux/20260406095820...@kernel.org/

Cheers,
Miguel

[Nika Krasnova]

On 2026-06-29 11:38:22 +0200, Miguel Ojeda wrote:
> For instance, instead of waiting for the MSRV bump, could we already
> use the upstream one since Rust 1.91.0? That means that we are already
> sure we are using the upstream one as-is.
>
> Or is there a reason to avoid that?

There is one, yes. First the toolchain picture (tested with
RUSTC_BOOTSTRAP=1):

- 1.85.0 (current MSRV): core::cfg_select does not exist -- only the
older
core::cfg_match (old `cfg(...)` arm syntax).
- 1.94.1: core::cfg_select present behind #![feature(cfg_select)], with
the final builtin behavior (single-brace expression position works).
- 1.95.0: core::cfg_select stable.

A gate (upstream when available, fallback when not) is possible, but
unlike
the cold_path case the fallback isn't a drop-in replacement. In item and
statement position the two are identical (single braces), but in pure
expression-operand position they are mutually exclusive: the builtin
takes
single braces, while the macro_rules needs an extra pair
(cfg_select! {{ ... }}), since it cannot put #[cfg] on a bare expression
without stmt_expr_attributes. No single spelling compiles on both.

That means a gate would force prohibiting expression-operand position
entirely (no portable spelling), which I would rather not do. I would
prefer to keep the macro_rules everywhere -- one consistent macro on
every
toolchain, expression position included -- and switch wholesale to
core::cfg_select once the MSRV reaches a version that has it. The switch
is
cheap: item/statement call sites are unchanged, and the only edit is
dropping the extra braces at any expression-position sites (there are
none
in the tree today).

I will still move it into std_vendor.rs and align the docs with
upstream's,
keeping the expression-position note since that is the one real
difference.

Does that work for you, or would you rather take the gate and drop
expression-operand support?

--
Nika Krasnova

[Miguel Ojeda]

On Mon, Jun 29, 2026 at 5:34 PM Nika Krasnova <ni...@nikableh.moe> wrote:
>
> - 1.94.1: core::cfg_select present behind #![feature(cfg_select)], with
> the final builtin behavior (single-brace expression position works).

The tracking issue says the latest change was in Rust 1.91.0. Did it
not work there? Were there changes after that?

> Does that work for you, or would you rather take the gate and drop
> expression-operand support?

Hmm... The end goal would to use `core::cfg_select`, so in general it
is a good idea to use the "real one" as soon as possible. In addition,
we can always wait for any case that doesn't work in the fallback (as
long as the behavior is the same for the cases that do work).

Therefore, we could limit ourselves to what would work today with the
fallback. If I understand you correctly, you are saying that even with
the conversion here, we wouldn't even need the expression case, no?

What is annoying about that is that there is definitely a risk of
someone using one of the cases that don't work on the fallback but
never actually testing on the minimum version -- even if we don't have
those today, someone may add it. And while it is "just" a compile
error that we would likely catch early in linux-next (like similar
things we need to handle), it is still painful.

So, yeah, I appreciate the advantage of having just a single compile
path, and if we can make it so that people cannot fall into cases that
would require extra cleanups/migration later on when we move to
`core`'s (even if `core` supports those), then that should be good,
i.e. if we want to go with this one in all versions, then we should
make sure we only allow that subset that cleanly maps to the future.

Now, to be honest, the easiest is to just wait a year and then start
using `core`'s directly... i.e. it is not like we are in a rush to
start using it anyway...

Cheers,
Miguel

[Nika Krasnova]

On 2026-06-29 21:07:34 +0200, Miguel Ojeda wrote:
> The tracking issue says the latest change was in Rust 1.91.0. Did it
> not work there? Were there changes after that?

Checked 1.91.0 directly: core::cfg_select is there behind
#![feature(cfg_select)] and behaves the same as 1.94.1 -- single-brace
expression position included. So 1.91.0 is the cutoff (RUSTC_VERSION >=
109100), nothing changed between 1.91.0 and 1.94.1.

> [...] If I understand you correctly, you are saying that even with

> the conversion here, we wouldn't even need the expression case, no?

That is correct. Everything in this series is item or statement
position;
nothing uses the expression-operand form.

> [...] if we want to go with this one in all versions, then we should

> make sure we only allow that subset that cleanly maps to the future.

Agreed. I'll restrict the fallback to exactly that subset
(item/statement, single braces) by dropping the expression-operand form.
Everyone hits the fallback until the MSRV bump, so a non-portable use
fails uniformly instead of compiling locally and breaking in linux-next.
The accepted subset is a strict subset of core::cfg_select, so the
eventual switch needs no call-site changes. (I'll also have the fallback
emit compile_error! on no-match, to match core.)

> Now, to be honest, the easiest is to just wait a year and then start
> using `core`'s directly... i.e. it is not like we are in a rush to
> start using it anyway...

Fair, I'm fine with dropping it. The counterargument is that the
fallback
is small and self-contained, and the conversion removes a chunk of
easy-to-desync pairs of #[cfg] now rather than in a year. Happy to send
a
v2 if you want it.

--
Nika Krasnova