From: Benno Lossin <benno.lossin@proton.me>
To: Miguel Ojeda <ojeda@kernel.org>, Alex Gaynor <alex.gaynor@gmail.com>
Cc: "Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
patches@lists.linux.dev
Subject: Re: [PATCH] rust: clarify the language unstable features in use
Date: Thu, 27 Mar 2025 22:13:22 +0000 [thread overview]
Message-ID: <D8RE79BLHK7K.1ZM2N5RBYGUY8@proton.me> (raw)
In-Reply-To: <20250327211302.286313-1-ojeda@kernel.org>
On Thu Mar 27, 2025 at 10:13 PM CET, Miguel Ojeda wrote:
> We track the details of which Rust features we use at our usual "live
> list" [1] (and its sub-lists), but in light of a discussion in the LWN
> article [2], it would help to clarify it in the source code.
>
> In particular, we are very close to rely only on stable Rust language-wise
> -- essentially only two language features remain (including the `kernel`
> crate).
>
> Thus add some details in both the feature list of the `kernel` crate as
> well as the list of allowed features.
>
> This does not over every single feature, and there are quite a few
> non-language features that we use too. To have the full picture, please
> refer to [1].
>
> Link: https://github.com/Rust-for-Linux/linux/issues/2 [1]
> Link: https://lwn.net/Articles/1015409/ [2]
> Suggested-by: Andreas Hindborg <a.hindborg@kernel.org>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
LGTM, so:
Reviewed-by: Benno Lossin <benno.lossin@proton.me>
And left two suggestions below.
> ---
> rust/kernel/lib.rs | 27 ++++++++++++++++++++-------
> scripts/Makefile.build | 8 ++++++++
> 2 files changed, 28 insertions(+), 7 deletions(-)
>
> diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
> index ba0f3b0297b2..660a3ab6f9d4 100644
> --- a/rust/kernel/lib.rs
> +++ b/rust/kernel/lib.rs
> @@ -12,21 +12,34 @@
> //! do so first instead of bypassing this crate.
>
> #![no_std]
> -#![feature(arbitrary_self_types)]
> -#![cfg_attr(CONFIG_RUSTC_HAS_COERCE_POINTEE, feature(derive_coerce_pointee))]
> -#![cfg_attr(not(CONFIG_RUSTC_HAS_COERCE_POINTEE), feature(coerce_unsized))]
> -#![cfg_attr(not(CONFIG_RUSTC_HAS_COERCE_POINTEE), feature(dispatch_from_dyn))]
> -#![cfg_attr(not(CONFIG_RUSTC_HAS_COERCE_POINTEE), feature(unsize))]
> +
> +// Please see https://github.com/Rust-for-Linux/linux/issues/2 for details on
> +// the unstable features in use.
> +
> +// Stable since Rust 1.79.0.
> #![feature(inline_const)]
> +
> +// Stable since Rust 1.81.0.
> #![feature(lint_reasons)]
> -// Stable in Rust 1.82
> +
> +// Stable since Rust 1.82.0.
> #![feature(raw_ref_op)]
> -// Stable in Rust 1.83
> +
> +// Stable since Rust 1.83.0.
> #![feature(const_maybe_uninit_as_mut_ptr)]
> #![feature(const_mut_refs)]
> #![feature(const_ptr_write)]
> #![feature(const_refs_to_cell)]
>
> +// Expected to become stable.
> +#![feature(arbitrary_self_types)]
> +
> +// `feature(derive_coerce_pointee)` is the one expected to become stable.
> +#![cfg_attr(CONFIG_RUSTC_HAS_COERCE_POINTEE, feature(derive_coerce_pointee))]
> +#![cfg_attr(not(CONFIG_RUSTC_HAS_COERCE_POINTEE), feature(coerce_unsized))]
> +#![cfg_attr(not(CONFIG_RUSTC_HAS_COERCE_POINTEE), feature(dispatch_from_dyn))]
> +#![cfg_attr(not(CONFIG_RUSTC_HAS_COERCE_POINTEE), feature(unsize))]
Does it make sense to add another comment in front of these three along
the lines of:
// Before Rust 1.82.0 `feature(derive_coerce_pointee)` doesn't exist, so enable the predecessor
// features.
> +
> // Ensure conditional compilation based on the kernel configuration works;
> // otherwise we may silently break things like initcall handling.
> #[cfg(not(CONFIG_RUST))]
> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> index 56be83024851..41a640990cfa 100644
> --- a/scripts/Makefile.build
> +++ b/scripts/Makefile.build
> @@ -226,6 +226,14 @@ $(obj)/%.lst: $(obj)/%.c FORCE
> # Compile Rust sources (.rs)
> # ---------------------------------------------------------------------------
>
> +# The features in this list are the ones allowed for non-`rust/` code.
> +#
> +# - Stable since Rust 1.81.0: `feature(lint_reasons)`.
> +# - Stable since Rust 1.82.0: `feature(asm_const)`, `feature(raw_ref_op)`.
> +# - Stable since Rust 1.87.0: `feature(asm_goto)`.
Probably a good idea to add:
# - Expected to become stable: `arbitrary_self_types`.
---
Cheers,
Benno
> +#
> +# Please see https://github.com/Rust-for-Linux/linux/issues/2 for details on
> +# the unstable features in use.
> rust_allowed_features := asm_const,asm_goto,arbitrary_self_types,lint_reasons,raw_ref_op
>
> # `--out-dir` is required to avoid temporaries being created by `rustc` in the
>
> base-commit: e6ea10d5dbe082c54add289b44f08c9fcfe658af
next prev parent reply other threads:[~2025-03-27 22:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-27 21:13 Miguel Ojeda
2025-03-27 22:13 ` Benno Lossin [this message]
2025-03-28 0:08 ` kernel test robot
2025-03-28 8:19 ` Miguel Ojeda
2025-05-12 13:49 ` Miguel Ojeda
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=D8RE79BLHK7K.1ZM2N5RBYGUY8@proton.me \
--to=benno.lossin@proton.me \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=gary@garyguo.net \
--cc=linux-kernel@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=patches@lists.linux.dev \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
/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
all inboxes | Powered by JetHome®