Rust wanted features #354

Note: there is the "A-rust-for-linux" label in the rust repository: https://github.com/rust-lang/rust/labels/A-rust-for-linux.

Please see as well upstream Rust's 2026 Rust for Linux Roadmap, in particular the "How we get there" and "Other topics" sections.

Features that we would like to see

Required (we almost certainly want them, even if we may have a workaround in place)

• Support packed types to be aligned or to contain aligned members.

  • RFC: [RFC] Allow packed types to transitively contain aligned types rust-lang/rfcs#3718.
  • Issue: Aligned structs in packed structs rust-lang/rfcs#3060.
  • Issue: E0587 error on packed and aligned structures from C rust-lang/rust#59154.
  • Issue: #[repr(align(N))] fields not allowed in #[repr(packed(M>=N))] structs rust-lang/rust#100743.
  • Related PR: Turn aligned-in-packed error into lint rust-lang/rust#162160.
  • And bindgen support for it: bindgen wanted features & bugfixes #353.

• pin-init / placement new / emplacement / in-place initialization / impl Init: better ergonomics than we get with our library solution, perhaps as a language feature.

  • Meta-Tracking Issue: Meta tracking Issue for in-place initialization rust-lang/rust#153825.
  • https://rust-for-linux.com/pin-init.
  • https://rust-for-linux.com/the-safe-pinned-initialization-problem.
  • RFC: RFC: Placement by return rust-lang/rfcs#2884.
  • Tracking Issue ("pin ergonomics"): Tracking issue for pin ergonomics rust-lang/rust#130494.
  • Generalized proposal:
    • HackMD: https://hackmd.io/@aliceryhl/BJutRcPblx.
    • Design Meeting: Design meeting: In-place Initialization rust-lang/lang-team#332.
    • Experiment proposal: Experiment proposal: In-place initialization rust-lang/lang-team#336.
  • Via outptrs proposal (out: Uninit<'o, T> output parameters and -> InPlace<'o, T> return types):
    • HackMD: https://hackmd.io/awB-GOYJRlua9Cuc0a3G-Q.
    • Zulip: https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/In-place.20initialization.20via.20outptrs/near/527575530.
    • HackMD: https://hackmd.io/@rust-for-linux-/H11r2RXpgl.
  • Fundamental issue of effects and in-place initialization:
    • HackMD: https://hackmd.io/@BennoLossin/HkBO0_oxbe.
    • Zulip: https://rust-lang.zulipchat.com/#narrow/channel/528918-t-lang.2Fin-place-init/topic/Fundamental.20Issue.20of.20Effects.20and.20In-place-init/with/558268061.
  • Zulip: https://rust-lang.zulipchat.com/#narrow/channel/486433-all-hands-2025/topic/Placement.20new.20in.20Rust/near/518803523.
  • Wiki for design work: https://github.com/rust-lang/beyond-refs.
  • See "Field projections" as well.

• Const generics (more support in general).

  • The more is supported, the better; e.g. feature(adt_const_params).
  • Our wishlist: Rust for Linux Const Generics Wishlist.
  • Const Generics Project Group: https://github.com/rust-lang/project-const-generics.
  • @BoxyUwU's document ("Const Generics Big Pictures"): https://hackmd.io/o7aNy5EgSROfSlA_eAdHxg?view#Slightly-Sparkly-Future-for-Const-Generics.
  • Minutes of the Rust <-> Rust for Linux call where const generics use cases were discussed with @BoxyUwU: https://hackmd.io/RsnVqqb0Qh2BhMW2g9Elew#Const-generics-Boxy.

• "Custom prelude": A more general prelude_import feature that allows us to avoid writing boilerplate in every kernel module (i.e. in every crate and every sub-mod), e.g. #![no_std], #![feature(...)], use kernel::prelude::*;, etc.

  • And the ability to detect unneeded imports on top of this one.
    • Klint Issue: Warn on import from non-prelude path if the type exists in prelude klint#5.
    • HackMD: https://hackmd.io/dYM3ljQMSrGB444O7RU_1Q?view#Warning-about-short-types.
    • Lore: https://lore.kernel.org/rust-for-linux/CANiq72k1b3DLEy_32ruWu1XBFK80oRDVzSer69ANL_232mmv-w@mail.gmail.com/.

• static_assert.

  • Status: t-libs-api decided to add documentation to assert! on how to do a static assert, in a function and at item level. t-lang was enthusiastic to have item-level const blocks. In principle, that would allow to use the same syntax (or to implement a static_assert!) that allows to use the generic parameters in certain contexts as well as be in top-level positions, though how it would work regarding pre-mono vs. post-mono details are not determined (currently const { ... } is intended to be post-mono while const _: () = ... is the pre-mono one).
  • RFC: Feature Request static asserts rust-lang/rfcs#2790.
  • RFC: Static asserts rust-lang/rfcs#1146.
  • Libs ACP: Add macro static_assert to perform compile-time assertion checking rust-lang/libs-team#325.
  • Related: Allow inline consts to reference generic params rust-lang/rust#96557 (1.62).
  • Related: Lang discussion: Item-level const {} blocks, and const { assert!(...) } rust-lang/lang-team#251.
  • Tracking Issue: Tracking Issue for item-level const blocks rust-lang/rust#149226.
  • PR: const blocks as a mod item rust-lang/rust#149174.
  • See:

    linux/rust/kernel/static_assert.rs

    Lines 5 to 9 in cae4454

    	/// Static assert (i.e. compile-time assert).
    	///
    	/// Similar to C11 [`_Static_assert`] and C++11 [`static_assert`].
    	///
    	/// The feature may be added to Rust in the future: see [RFC 2790].

• build_assert.

  • Especially ways to fail earlier and/or improve the error messages, similar to GCC's and Clang's error/warning attribute.
  • @nbdd0121 suggests: "One option is to extract debug information (if compiled with that, that is) and to find the call-site".
  • Lore (on the confusing error): https://lore.kernel.org/rust-for-linux/g63h5f3zowy375yutftautqhurflahq3o5nmujbr274c5d7u7u@j5cbqi5aba6k/.
  • Zulip (on the confusing error): https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/build.20checked.20IoMem.20access/near/501675170.
  • See:

    linux/rust/kernel/build_assert.rs

    Lines 28 to 34 in cae4454

    	/// Asserts that a boolean expression is `true` at compile time.
    	///
    	/// If the condition is evaluated to `false` in const context, `build_assert!`
    	/// will panic. If the compiler or optimizer cannot guarantee the condition will
    	/// be evaluated to `true`, a build error will be triggered.
    	///
    	/// [`static_assert!`] should be preferred to `build_assert!` whenever possible.

  • Recently (2026) being proposed for C (Nxxxx) and C++ (P4021R0) too.

• Inline assembly: memory operands support.

  • Needed to write more efficient code, e.g. for reimplementing atomics in the Rust side.
  • See "Memory operands" section in the inline asm RFC: https://rust-lang.github.io/rfcs/2873-inline-asm.html#memory-operands.
  • Lore (status report from @fbq): https://lore.kernel.org/rust-for-linux/Zh6_d1T48qpANoCk@boqun-archlinux/
  • Lore: https://lore.kernel.org/rust-for-linux/ZWdv_jsaDFJxZk7G@Boquns-Mac-mini.home/.
  • Cc: @nbdd0121 @fbq.

• -Coverflow-checks=report (allowing to customize the handler).

  • A new mode that allows to "report and continue" (wrapping), like UBSan and similar tools.
  • It could be useful as an "intermediate" point between just wrapping or a panic.
  • "Reporting" should be customizable via a handler, e.g. the kernel could map it to WARN*() (which could still panic depending on panic_on_warn).
  • We should ideally be able to support ONCE variants, i.e. being able to warn once per call site.
  • Ideally we should be able to customize the behavior, e.g. choosing saturation instead of wrapping.
  • RFC (possible first step): [RFC] externally implementable functions rust-lang/rfcs#3632.
  • RFC (alternative possible first step): Externally implementable traits rust-lang/rfcs#3645.
  • 2025H1 project goal: Add project goal: Externally Implemtable Items (EII) rust-lang/goals#198.
  • Tracking Issue (Externally Implementable Items (EIIs), feature(extern_item_impls)): Tracking Issue for externally implementable items rust-lang/rust#125418.
    • PR: Recoverable overflow rust-lang/rust#157314.
    • Cc: @jdonszelmann @m-ou-se.
  • Lore (ktime_t): https://lore.kernel.org/rust-for-linux/CANiq72nGHhgRjfMOhz=ss51q2egHYexPMVvWTr0RES9WAmMF=A@mail.gmail.com/. In particular, Thomas Gleixner says a warning may be appropriate, but not a panic.

• UnsafePinned (feature(unsafe_pinned)).

  • Used by: Opaque (currently !Unpin via PhantomPinned, which is what gives us the ability to have aliased mutable references to those), which in turn is used everywhere.
  • Tracking Issue: Tracking Issue for RFC 3467: UnsafePinned rust-lang/rust#125735.
  • RFC: UnsafePinned: allow aliasing of pinned mutable references rust-lang/rfcs#3467.
  • PR: Initial UnsafePinned implementation [Part 1: Libs] rust-lang/rust#137043 (1.88).
  • PR: Initial UnsafePinned implementation [Part 2: Lowering] rust-lang/rust#139896 (?).
  • PR (at least noalias): ... (?).
  • Lore: https://lore.kernel.org/rust-for-linux/DK4JLF37634O.8XPVFOVD80TP@garyguo.net/.

• Bitfield support, including whatever is needed to describe existing C ones in bindgen's output.

  • RFC: Add bitfields support rust-lang/rfcs#3113.

• unsafe macros.

  • Marking macros as unsafe explicitly, so that unsafe is required to call then, and so that Clippy and other tooling can lint based on that (e.g. requiring # Safety sections and // SAFETY: comments).
  • Note: this is not about treating all macros as unsafe (Rust wanted features #354 (comment)).
  • UCG issue: Safety/soundness of macros rust-lang/unsafe-code-guidelines#278.
  • Possibly via macros 2.0: Tracking issue: declarative macros 2.0 rust-lang/rust#39412.

• fn_cast!.

  • i.e. a function item transmute, but when KCFI is enabled, uses a trampoline that transmutes the arguments.
  • Issue: fn_cast! macro rust-lang/rust#140803.
  • Status: waiting on lang experiment.
  • Background: Can CFI be made compatible with type erasure schemes? rust-lang/rust#128728.
  • Could it be done safely for certain subsets? If so, would we want a unsafe_fn_cast! and fn_cast! split. TODO: ask zerocopy and Project Safe Transmute.
  • Language concern about the [guarantee]((https://doc.rust-lang.org/std/primitive.fn.html#abi-compatibility) of function pointer ABI-compatibility: pointers to different T, even if they have the same metadata, they are not actually compatible under CFI.
  • Cc: @Darksonn.

• Improving safety comments maintenance (and tooling for that), contracts, Rust Safety Standard.

  • Project goals proposed in 2026H1, they will keep us in the loop.
  • @BennoLossin's approach ("Rust Safety Standard"):
    • Kangrejos: https://kangrejos.com/2024/Rust%20Safety%20Standard.pdf.
    • Lore: https://lore.kernel.org/rust-for-linux/20240717221133.459589-1-benno.lossin@proton.me/.
  • HackMD ("Automated checking of unsafe code requirements"): https://hackmd.io/@predrag/ByVBjIWlyx.
  • Zulip: https://rust-lang.zulipchat.com/#narrow/channel/486433-all-hands-2025/topic/Naming.20safety.20requirements.20.26.20invariants/near/518801980.
  • tag-std:
    • https://github.com/Artisan-Lab/tag-std.
    • Issue: Support safety attributes in Rust for Linux safer-rust/safety-tags#3.

• Equivalent of the upcoming Clang kcfi_salt C attribute.

  • Lore: https://lore.kernel.org/lkml/CABCJKufPphD3en91N89yekUam4Nv7+C7YPJMv7h2SmZcyhGhdA@mail.gmail.com/.
  • PR (LLVM): [Clang][attr] Add 'cfi_salt' attribute llvm/llvm-project#141846.

• Sealed traits.

  • If it existed, then we would want to use it already. We may end up implementing a #[sealed] macro or use an existing library.
  • Tracking Issue (Restrictions, which could implement short-hand syntax like sealed): Tracking Issue for Restrictions rust-lang/rust#105077.
  • RFC: Restrictions rust-lang/rfcs#3323.
  • Lore: https://lore.kernel.org/rust-for-linux/DFSMRQFIYQPO.1A38Y84XZ1GZO@garyguo.net/.
  • Cc: @nbdd0121.

• Niche optimizations.

  • In particular, at least for Rust enums that contain pointers to aligned objects (e.g. 4 byte alignment in XArray, or to a page, etc.).

  • XArray wants them for the Rust reimplementation of the data structure -- Andreas writes:

    enum Node {
        Pointer(KBox<Node>),
        Internal(u8),
        Value(u8),
    }

    The size of Node is 2 words, one for the discriminant and one for the value.
    However, because Node has an alignment of at least 4 bytes, the discriminant could
    be encoded in the lower two bits of the first word.

  • Zulip: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/Optimisation.20.20for.20enums.20of.20pointers.20to.20aligned.20objects/with/569743750.

  • Cc: @metaspace.

• TAIT (feature(type_alias_impl_trait)) + new trait solver (-Znext-solver) makes pin-init unsound.

  • Issue: TAIT + next-solver will allow constructing a unit struct without mentioning its type, causing pinned-init to be unsound. rust-lang/rust#153535.
  • PR (pin-init): replace shadowed return token by unsafe-to-create token pin-init#117.
  • RFC comment: Path Inference rust-lang/rfcs#3444 (comment).
  • Cc: @BennoLossin.

Nice to have (not critical, we could workaround if needed, etc.)

• A way to easily export in the prelude macros generated by macros.

  • Related: resolve: Modularize crate-local #[macro_export] macro_rules rust-lang/rust#52234.

• -masm= equivalent (i.e. the ability to configure the assembly syntax default).

  • The kernel uses the AT&T syntax and thus our asm! blocks will need options(att_syntax).
  • As a workaround, a macro that expands to asm! with the option set should be fairly straightforward (Experimental tracepoint support #1084 (comment)).
  • Users Forum: https://users.rust-lang.org/t/macro-for-att-syntax-asm/115675.
  • However, having a flag (or similar) that sets the default would be ideal (possibly allowing options(intel_syntax) in the other case).

• Support in asm! for several string literals.

  • i.e. allow core::arch::asm!("" "");.
  • We use some #defines to reuse assembly in both C and Rust (RSCPP Kbuild rule), and GCC/Clang allow e.g. asm("" "");, thus it is easiest if Rust's asm! allows it as well.
  • Our workaround is to wrap it with ::kernel::concat_literals!(...).
  • Comparison: https://godbolt.org/z/E8jsPT79Y.
  • Zulip: https://rust-lang.zulipchat.com/#narrow/stream/425075-rust-for-linux/topic/asm-goto.20stabilization/near/457365566.
    Amanieu says:

    We specifically designed asm! to work well with rustfmt, where each line can be comma-separated and appear on a different line after formatting. For concatenation within a line, we intentionally chose to make users use concat!.

    Which allows for things like this where you can add coments on individual lines of inline assembly code.

• #[may_dangle].

  • To give some of our types, like our custom Arc, the same abilities as the standard library's.
  • Tracking Issue: #[may_dangle], a refined dropck escape hatch (tracking issue for RFC 1327) rust-lang/rust#34761.

• Extern types (extern { type S; }).

  • Tracking Issue: Tracking issue for RFC 1861: Extern types rust-lang/rust#43467.
  • We could replace some uses of Opaque<T>: Opaque<T> carries a T (it is MaybeUninit + UnsafeCell + PhantomPinned), but in some use cases we just have them behind a pointer, and thus we would like just a pointer to an actually opaque type, which would prevent e.g. calling mem::swap on them.
  • bindgen could also use the functionality instead of the current recommended workaround in its generated code. In addition, bindgen could perhaps be passed a list of types that should be handled as extern types on purpose, rather than provide the full definition even if available.
  • RFC: extern types rust-lang/rfcs#1861.
  • Blocked on: extern type cannot support size_of_val and align_of_val rust-lang/rust#49708.
  • Related (requires extern types and provides a way to solve the blocker above): Hierarchy of Sized traits rust-lang/rfcs#3729.

• Support more than just integer literals (e.g. const) in attributes like repr(align(...)).

  • e.g. we get const PAGE_SIZE: usize = 4096; from bindgen, and ideally we would be able to do #[repr(align(PAGE_SIZE))] struct S;.
  • Issue (for const): #[repr(align(…))] should allow arbitrary constant expressions, not just integer literals rust-lang/rust#52840.
  • PR (for const): Add gated const item paths support for selected builtin attributes. rust-lang/rust#154708.
  • Lore: https://lore.kernel.org/rust-for-linux/20241119112408.779243-3-abdiel.janulgue@gmail.com/.

• Leveraging the same magic Box has.

  • The kernel has its own alloc module with our own KBox, KVec etc.
  • UCG: What are the uniqueness guarantees of Box and Vec? rust-lang/unsafe-code-guidelines#326.
  • RFC: RFC: No (opsem) Magic Boxes rust-lang/rfcs#3712.

• Pattern types (ranges, bounded integers, type constraints...).

  • Tracking Issue: Tracking Issue for pattern types (pattern_types) rust-lang/rust#123646.
  • We often have cases where it would be nice to statically know/restrict/guarantee allowed set of values on integers, be it a range or other constraints like Alignment and generic PowerOfTwo.
  • Lore: https://lore.kernel.org/rust-for-linux/DD5D59FH4JTT.2G5WEXF3RBCQJ@nvidia.com/.

• Attributes on expressions (feature(stmt_expr_attributes)), e.g. for #[allow(...)] or #[cfg(...)].

  • Tracking Issue: Tracking issue for stmt_expr_attributes: Add attributes to expressions, etc. rust-lang/rust#15701.
  • RFC: RFC for attributes on statements and blocks. rust-lang/rfcs#16.
  • Lore: https://lore.kernel.org/rust-for-linux/CANiq72kqAO5Xms8wJbH3tf+Tcet6ORDLa+Mm3Rw+jNSm7WwbSw@mail.gmail.com/.

• A solution for the dma_read! soundness issue.

  • rustc's dangerous_implicit_autorefs lint would work (because in the Linux kernel we control what lints are enabled) if it was meant to work in all cases, but @Urgau points out the lint was not intended to do so:

    This lint was also carefully calibrated to only trigger in certain situation, as to only target the cases where it matters the most. See this explanation for the currently implement rules.

  • Zulip: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/Soundness.20of.20.60dma_read!.28.29.60/near/571998329.
  • Rust Internals (offset_of_val!): https://internals.rust-lang.org/t/offset-of-val/23977.
  • Rust Zulip: https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/dangerous_implicit_autorefs.20and.20Box/near/572028697.

• Items only public for a given macro.

  • Or at least for macros in the current module or crate.
  • i.e. so that the items can only be used by the macro that needs them, but not others (even if the docs are hidden).
  • HackMD: https://hackmd.io/jDrRNEK7RpGBB5lxuEKyOA.

• A Rust specification/standard/official reference.

  • Issue: Expand the Rust Reference to specify more aspects of the Rust language rust-lang/goals#394.
  • Lore (original Rust for Linux RFC): https://lore.kernel.org/lkml/20210414184604.23473-1-ojeda@kernel.org/.

• const functions only meant to be called in const context (i.e. like C++'s consteval).

  • Sometimes we want to have const fns, but they are not intended to be called at runtime (e.g. because they panic, which we generally avoid in the kernel).
  • Lore (#[const_eval_only]): https://lore.kernel.org/rust-for-linux/DKZSSBO7KNYJ.1YCSZDT87W7PX@garyguo.net/.
  • Lore: https://lore.kernel.org/rust-for-linux/CAGSQo03hxp0PSMK0rCvMKnpUCnktwL09ao2NSvmQLHjTsfBWaw@mail.gmail.com/.

• #[diagnostic::do_not_recommend] for methods and/or traits (or perhaps a #[diagnostic::prefer_recommend]).

  • Lore: https://lore.kernel.org/rust-for-linux/DJO4SC0M6BCM.B7RP36WUWCM9@garyguo.net/.
  • Internals: https://internals.rust-lang.org/t/do-not-recommend-for-traits-themselves/24431.
  • Blocker for: Generalize impl<T> Clone for Box<T> to unsized types rust-lang/rust#146381 (comment).
  • Experiment similar in spirit: [WIP] Support #[rustc_on_unimplemented] on methods rust-lang/rust#156400.

• Better NonZero ergonomics (f(1) integer literal coercion, 1nz literals or other solutions).

  • Currently we are considering a nz! macro that expands to const { ::core::num::NonZero::new($v).unwrap() }.
  • Issue: Feature Request: NonZeroInt literal coersion rust-lang/rust#69329.
  • Lore (cv! macro, more general): https://lore.kernel.org/rust-for-linux/20260901-cv-v2-0-446bc69d2ade@nvidia.com/.
  • Lore (nz! macro): https://lore.kernel.org/rust-for-linux/20260817-chid-v7-3-a5872e64d8f4@nvidia.com/.
  • Lore (original discussion): https://lore.kernel.org/rust-for-linux/CANiq72m=bbjgMZy-BCsB0hajMJcKb+j=jeMN=e4++B-XSUOzeg@mail.gmail.com/.
  • Discussion with upstream Rust: https://hackmd.io/@rust-lang-team/SyewZYnvMl.

• Better integer casts (avoiding as).

  • libs Issue: Meta-ACP: Integer cast methods rust-lang/libs-team#833.
  • See also feature(integer_extend_truncate) in Rust unstable features needed for the kernel #2.
  • Discussion with upstream Rust: https://hackmd.io/@rust-lang-team/SyewZYnvMl.

Discussion needed

• Will &mut T be always treated as *mut T for !Unpin types?

  • Currently this is the case: https://github.com/rust-lang/rust/blob/1c988cfa0b7f4d3bc5b1cb40dc5002f5adbfb9ad/compiler/rustc_middle/src/ty/layout.rs#L2497-L2500.
  • Issue: Resolve unsound interaction between noalias and self-referential data (incl. generators, async fn) rust-lang/rust#63818.
  • Used in: rust/kernel/kasync/net.rs.

• Some feature to help with partial borrowing, e.g. "view types".

• A way to prove blocks of code / functions do not panic / disabling panics locally (or in a TU) / linting / PANIC: enforced comments...

  • Potentially useful, depending on the details. The kernel is (currently) unconditionally -Cpanic=abort.
  • Issue: no-panic as a language feature rust-lang/project-error-handling#49.
  • Upstream Rust open to discussion and even a potential project goal for 2026H1: https://hackmd.io/BKtSH2Q_Q8ePDZ5-RJA7-A.
  • Related: "-Coverflow-checks=report (allowing to customize the handler)".
  • Lore (on overflow and no panics): https://lore.kernel.org/rust-for-linux/CANiq72=nGbziZCKt=AneE_vXw76i=+td0dSVfbOJ8kJ9eYHw9w@mail.gmail.com/
  • Lore (on unwrap Clippy lints): https://lore.kernel.org/rust-for-linux/CANiq72nJiJ4K6jy17x-YRYnJpjqTnohYWvoFrLkYQp0X4tLL=w@mail.gmail.com/
  • Lore (on panics from debug assertions triggered from user interaction being a CVE): https://lore.kernel.org/rust-for-linux/CANiq72nAagBBPhyU3XdETMKBuFPbMMRaSTStWPpyLnByYPP=+A@mail.gmail.com/

• Disabling particular unsafe precondition checks under -Cdebug-assertions=y.

  • The kernel is always compiled with high levels of optimizations (currently either -O2 or -Os) and we provide the option to enable debug assertions in Kconfig.

  • Since Toggle assert_unsafe_precondition in codegen instead of expansion rust-lang/rust#120594 (1.78), -Cdebug-assertions=y will always check all unsafe preconditions, without a way to opt-out for particular cases (e.g. previously one could write a unreachable_unchecked for a fallible API even if the unchecked version of the API had a debug_assert, but now that is always checked), which can have a fairly big impact in runtime (due to branches/calls, which in turn makes the compiler not be able to apply other optimizations too in certain cases currently).

  • Since Put checks that detect UB under their own flag below debug_assertions rust-lang/rust#123411 (1.79), there is a new flag, -Zub-checks (Tracking Issue for feature(cfg_ub_checks) and -Zub-checks rust-lang/rust#123499), which inherits the default from -Cdebug-assertions (similar to -Coverflow-checks). This helps, but there is still no way to selectively disable particular cases.

  • At the moment we are not aware of tests or use cases requiring particular performance targets for those builds in the Rust side, but it is possible that at some point they may come, or that we may need to optimize certain hot parts to keep the debug builds reasonably fast.

  • Thus it would be ideal to have a way to selectively disable certain checks per-call site (i.e. not just per check but for particular instances of a check), even if the vast majority of the checks remain in place.

  • Try enabling precondition checks on ptr::{read,write} rust-lang/rust#129498 introduces the #[rustc_no_ubchecks] attribute, @saethlin says in Disabling particular unsafe precondition checks under -Cdebug-assertions=y rust-lang/rust#120969 (comment):

    In #129498 I'm experimenting with ways to get the precondition checks for ptr::{read,write} enabled. One of the things I'm trying is inventing an attribute currently called #[rustc_no_ubchecks] which makes the MIR optimization pipeline delete checks that got inlined into the body of the indicated function. I don't think this idea is particularly good or possible to stabilize, but it is easy to implement. If it lands, it would be a thing for RFL to play around with, just in case you happen to find a use for it.

    This could probably be easily extended to (again) a crude general mechanism by putting the attribute on a closure to disable checks in a few lines of code instead of "a whole function". If the inliner cooperates.

  • Kept in this list since a solution could involve several aspects of Rust (compiler/language/library).

  • Issue: Disabling particular unsafe precondition checks under -Cdebug-assertions=y rust-lang/rust#120969.

  • Tracking Issue for "things to do after Toggle assert_unsafe_precondition in codegen instead of expansion rust-lang/rust#120594": Totally-not-a-tracking-issue for UB-detecting debug assertions in the standard library rust-lang/rust#120848.

• Support and communication between the Rust and C (LKMM) memory models.

  • Issue: Memory ordering model policy/plan #1067.
  • UCG Issue: Support for Linux kernel memory model rust-lang/unsafe-code-guidelines#348.
  • UCG Issue: Document the current recommendation when Rust is used to communicate with a different memory ordering model rust-lang/unsafe-code-guidelines#476 (comment).
  • UCG Issue: What about: mixed-size atomic accesses rust-lang/unsafe-code-guidelines#345.
  • UCG Issue: How can we allow read-read races between atomic and non-atomic accesses? rust-lang/unsafe-code-guidelines#483.
  • Rust Zulip: https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/.E2.9C.94.20Rust.20and.20the.20Linux.20Kernel.20Memory.20Model/near/422047924 (in turn from https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/Volatile.20implies.20atomic.3F/near/418403842).
  • 2024-03-22 23:38 [WIP 0/3] Memory model and atomic API in Rust:
    • Lore: https://lore.kernel.org/rust-for-linux/20240322233838.868874-1-boqun.feng@gmail.com/
    • Rust Zulip: https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/Memory.20model.20discussion.20on.20LKML/near/429590163
    • LWN: https://lwn.net/Articles/967049/
  • Lore: https://lore.kernel.org/rust-for-linux/ae8ac31f-c6ad-46ae-80dd-10ec081a16d1@ralfj.de/.
  • Atomic memcpy:
    • RFC: [RFC] AtomicPerByte (aka "atomic memcpy") rust-lang/rfcs#3301.
    • Rust Zulip: https://rust-lang.zulipchat.com/#narrow/channel/425075-rust-for-linux/topic/Atomic.20memcpy/near/574595496.
    • Lore (thread with Peter et al.): [PATCH v3] rust: page: add byte-wise atomic memory copy methods.
  • Cc: @fbq @RalfJung @Darksonn.

• A solution for updating the kernel (e.g. fixing a bug in core) without forcing recompilation of loadable/out-of-tree Rust modules.

  • Likely useful for some downstream, out-of-tree users, but unclear how many cases could avoid recompilation.
  • Generics are the main issue. Could generics be "instantiated" for some well-known types, to reduce the cases where a recompilation may be needed?
  • #[inline] code as well, though that could be perhaps disabled (ideally still allowing inlining in-tree, but providing the symbol for out-of-tree modules).
  • An initial solution for non-generics could be RFC: #[export] (dynamically linked crates) rust-lang/rfcs#3435 together with Tracking Issue for the experimental crabi ABI rust-lang/rust#111423. See [2025H1] Research: How to achieve safety when linking separately compiled code rust-lang/goals#155 as well.

• A solution for getting unique/stable function pointers to "generic callbacks" like devres_callback<T>().

  • Rust Zulip: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Linux.20kernel.3A.20duplicate.20function.20definition/near/438391087.
  • Zulip: https://rust-for-linux.zulipchat.com/#narrow/stream/415254-DRM/topic/Duplicate.20symbols/near/438026564.

• Improved C interop/support.

  • i.e. the ability to import and use C headers directly in Rust / integrated bindgen/cbindgen support, accepting GNU/Clang-like flags, etc.
  • These topics have been a recurrent topic of discussion in Rust for Linux over the years. Any improvement here would be helpful/welcome for the kernel integration.
  • Potential "2024 Rust project goal": https://rust-lang.github.io/rust-project-goals/2024h2/Seamless-C-Support.html (PR: Add two draft project goals: seamless C support, and relaxing the orphan rule rust-lang/goals#3).

• Relaxing the orphan rule.

  • Tracking Issue: experiment with relaxing the orphan rule rust-lang/rust#136979.

  • In the kernel, internal APIs are not stable (https://docs.kernel.org/process/stable-api-nonsense.html): any changes are required to fix users/callers as needed. Out-of-tree modules are expected to follow and change as needed too. Therefore, it makes sense to relax the orphan rule within the kernel.

    [ I asked @bjorn3 about this idea in 2022, and he suggested introducing "coherence domains", which we then discussed later on with @nbdd0121 et al.: "One option would be to introduce a concept of coherence domains whereby all crates in a coherence domain are considered as a monolithic whole with respect to the coherence rules. The standard library could then have a coherence domain and the kernel code could have another coherence domain.". It could possibly be useful for other multi-crate/workspace projects as well. @bjorn3 mentioned it again in 2026. - Miguel ]

  • Potential "2024 Rust project goal": https://rust-lang.github.io/rust-project-goals/2024h2/Relaxing-the-Orphan-Rule.html (PR: Add two draft project goals: seamless C support, and relaxing the orphan rule rust-lang/goals#3).

  • Internals: https://internals.rust-lang.org/t/limited-opt-out-of-orphan-rule/21709.

  • Zulip: https://rust-lang.zulipchat.com/#narrow/channel/425075-rust-for-linux/topic/Relaxing.20the.20orphan.20rule/near/483578919.

  • Related: Tracking issue for fundamental feature rust-lang/rust#29635.

  • Related: Allow incoherent trait implementations rust-lang/rust#150652.

  • Internals: https://internals.rust-lang.org/t/pre-rfc-make-orphan-rule-stricter-for-trait/23561.

  • Blogpost from @BoxyUwU (summary of coherence, existing proposals and new one: incoherent traits): https://www.boxyuwu.blog/posts/an-incoherent-rust/.

• Numerical comparisons in conditional compilation.

  • For instance, for version testing: #[cfg(CONFIG_RUSTC_VERSION >= 107900)].
    • For pure rustc version cases, #[cfg(version(...))] or #[cfg(accessible(...))] may be alternatives (cfg(version(...)) was finally decided to return true when matching against nightly (by default, i.e. unless -Zassume-incomplete-release is given), which is generally what we want, since we would expect developers to use the latest nightlies only).
    • Tracking Issue: Tracking issue for RFC 2523, #[cfg(version(..))] rust-lang/rust#64796.
    • Tracking Issue: Tracking issue for RFC 2523, #[cfg(accessible(::path::to::thing))] rust-lang/rust#64797.
    • Stabilization PR: Stabilize #[cfg(version(...))] rust-lang/rust#141137.
  • We work around it by defining cfgs on the fly for each condition/feature/etc. via Kconfig, which is also a more flexible in general.
  • Internals: https://internals.rust-lang.org/t/conditional-compilation-const-ord/16191.

• A better way to handle cfg conditionals, such as the upcoming cfg_select! upstream.

  • Tracking Issue: Tracking issue for cfg_select (formerly cfg_match) rust-lang/rust#115585.
  • Issue: add if_cfg! macro #1183.
  • PR: stabilize cfg_select! rust-lang/rust#149783.
  • Lore: https://lore.kernel.org/rust-for-linux/CANiq72=rd+AcTSs3QNf+fju1pMg7peb0QK_B1jfVEr4E2BNrzw@mail.gmail.com/.

• Safe transmute.

  • Currently planning to vendor zerocopy.
  • See fn_cast! -- could that be made safe for certain subsets of casts?

• Enough specialization to improve the performance of our alloc (feature(min_specialization)).

  • From: https://rust-for-linux.zulipchat.com/#narrow/stream/288089-General/topic/.60Arc.60.20and.20.60ARef.60.
  • Tracking Issue: Tracking issue for specialization (RFC 1210) rust-lang/rust#31844.
  • Used by: nothing yet (which is why it is in this list), but potentially in Arc.
  • Status: while full specialization is unsound, min_specialization may be sound. We would only want to allow it for Arc, rather than subsystems in general. Nevertheless, it is very tricky to use properly at the time ("even rustc devs mess up with min_specialization."). In addition, there are bugs remaining, e.g. just enabling min_specialization is currently unsound on its own (With min_specialization enabled, an incomplete impl for a non-static type will delegate method calls to a less-specific impl with a 'static bound rust-lang/rust#79457).

• !Move, Forget (for lock guards), linear types...

• Lifting limitations of const traits.

  • Lore: link needed.

• Partial initialization of locals (feature(partial_init_locals)).

  • Issue: Tracking Issue for partial_init_locals rust-lang/rust#153699.
  • PR: Allow phased initializing structs rust-lang/rust#152774.

• Freeze / NoCell / ~zerocopy::Immutable.

  • Gary writes:

    If Freeze is just natively supported by the language, then zerocopy could use it and then we don't need to derive it everywhere even if none of our code relies on IntoBytes + !Immutable.

  • Jack writes:

    A caveat is that Freeze and zerocopy::Immutable have different semantics. Freeze is shallow and maybe not implemented for PhantomData<T: !Freeze>, whereas zerocopy::Immutable is recursive w.r.t. indirection and definitely implemented for PhantomData<T: !Freeze>. It's also important that zerocopy::Immutable is manually implementable, as that allows us to support special wrappers like ReadOnly<T: !Freeze>.

  • RFC: core::marker::NoCell in bounds (previously known an Freeze) rust-lang/rfcs#3633.
  • Zulip: https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Reviving.20the.20Freeze.20RFC.20.283633.29/near/590242864.

• Avoiding Unicode tables (assuming we don't use anything from core that requires them) or avoiding duplicating the tables (assuming the kernel could use Rust's ones for existing use cases, which assumes the kernel ones can be updated easily somehow).

  • Zulip: https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Deduplicating.20unicode.20tables.20in.20Rust.20projects/near/607872253.

Low priority (we will likely not use them in the end)

• A way to elegantly handle "noop conditional compilation wrappers".

  • Marking callers does not scale -- the C side uses these wrappers to restrict conditional compilation to headers/callees as much as possible.
  • See e.g. rust: kernel: support !CONFIG_PRINTK #669.

• quote as part of the freestanding standard library.

  • Tracking Issue: Tracking issue for the quote! macro in proc_macro rust-lang/rust#54722.

• syn as part of the freestanding standard library.

  • Even if it only covers a subset of the syntax, older versions of the syntax or uses "unknown" nodes.

Done (stabilized, fixed, not needed anymore, etc.)

• Remove the need for defining __rust_* methods.

  • Issue: Investigate why no GlobalAlloc-related symbols are generated #68.
  • PR: Support #[global_allocator] without the allocator shim rust-lang/rust#86844 (1.71).

• feature(let_else).

  • Moved into the main list, since it got implemented, we started to use it, and it got stabilized.

• feature(const_refs_to_static) & feature(const_refs_to_static).

  • Moved into the main list since our use case was implemented.

• feature(lint_reasons).

  • Moved to the main lint, since it was stabilized and we started using it since v6.13.

• Inline assembly: asm goto support (feature(asm_goto)).

  • Moved into the main list since it got implemented.

• Allow #[repr(Rust)].

  • Useful to be explicit about particular cases that would normally need e.g. the C representation, such as silencing Lint against #[no_mangle] for non-repr(C) pub statics rust-lang/rust-clippy#11219 (see Clippy's list).
  • PR: Allow explicit #[repr(Rust)] rust-lang/rust#114201 (1.74).

• assume-like mechanism (core::hint::assert_unchecked).

  • Tracking Issue: Tracking Issue for hint::assert_unchecked rust-lang/rust#119131.
  • Status: getting stabilized Stabilize hint::assert_unchecked rust-lang/rust#123588 (1.81).

• Make unsafe_op_in_unsafe_fn the default dialect in a future edition.

  • Issue: Tracking Issue for "unsafe blocks in unsafe fn" (RFC #2585) rust-lang/rust#71668.
  • Our feedback: Tracking Issue for "unsafe blocks in unsafe fn" (RFC #2585) rust-lang/rust#71668 (comment).
  • FCP for warn-by-default in 2024: Tracking Issue for "unsafe blocks in unsafe fn" (RFC #2585) rust-lang/rust#71668 (comment).
  • PR: Change unsafe_op_in_unsafe_fn to be warn-by-default from edition 2024 rust-lang/rust#112038.
  • PR: Add MVP suggestion for unsafe_op_in_unsafe_fn rust-lang/rust#112017.

• Naked functions.

  • Tracking Issue: Tracking Issue for RFC #2972: Constrained Naked Functions  rust-lang/rust#90957.
  • PR: Stabilize naked_functions rust-lang/rust#134213 (1.88).

• likely/unlikely-like mechanism.

  • Moved into the main list since it got implemented.

• Field projections (feature(field_projections)).

  • Moved into the main list since the first implementation PR landed.