You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
pin-init / placement new / emplacement / in-place initialization / impl Init: better ergonomics than we get with our library solution, perhaps as a language feature.
"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.
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).
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.
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).
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.
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!(...).
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.
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.
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.
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 @Urgaupoints 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.
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).
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.
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).
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).
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.
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. @bjorn3mentioned it again in 2026. - Miguel ]
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).
Note: there is the "A-rust-for-linux" label in the
rustrepository: 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.
bindgensupport for it:bindgenwanted 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.out: Uninit<'o, T>output parameters and-> InPlace<'o, T>return types):Const generics (more support in general).
feature(adt_const_params)."Custom prelude": A more general
prelude_importfeature 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.static_assert.assert!on how to do a static assert, in a function and at item level. t-lang was enthusiastic to have item-levelconstblocks. In principle, that would allow to use the same syntax (or to implement astatic_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 (currentlyconst { ... }is intended to be post-mono whileconst _: () = ...is the pre-mono one).static_assertto perform compile-time assertion checking rust-lang/libs-team#325.const {}blocks, andconst { assert!(...) }rust-lang/lang-team#251.constblocks rust-lang/rust#149226.constblocks as amoditem rust-lang/rust#149174.linux/rust/kernel/static_assert.rs
Lines 5 to 9 in cae4454
build_assert.error/warningattribute.linux/rust/kernel/build_assert.rs
Lines 28 to 34 in cae4454
Inline assembly: memory operands support.
-Coverflow-checks=report(allowing to customize the handler).WARN*()(which could still panic depending onpanic_on_warn).ONCEvariants, i.e. being able to warn once per call site.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)).Opaque(currently!UnpinviaPhantomPinned, which is what gives us the ability to have aliased mutable references to those), which in turn is used everywhere.UnsafePinnedimplementation [Part 1: Libs] rust-lang/rust#137043 (1.88).UnsafePinnedimplementation [Part 2: Lowering] rust-lang/rust#139896 (?).noalias): ... (?).Bitfield support, including whatever is needed to describe existing C ones in
bindgen's output.unsafemacros.unsafeexplicitly, so thatunsafeis required to call then, and so that Clippy and other tooling can lint based on that (e.g. requiring# Safetysections and// SAFETY:comments).unsafe(Rust wanted features #354 (comment)).fn_cast!.transmute, but when KCFI is enabled, uses a trampoline that transmutes the arguments.fn_cast!macro rust-lang/rust#140803.unsafe_fn_cast!andfn_cast!split. TODO: askzerocopyand Project Safe Transmute.T, even if they have the same metadata, they are not actually compatible under CFI.Improving safety comments maintenance (and tooling for that), contracts, Rust Safety Standard.
Equivalent of the upcoming Clang
kcfi_saltC attribute.Sealed traits.
#[sealed]macro or use an existing library.sealed): Tracking Issue for Restrictions rust-lang/rust#105077.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:
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) makespin-initunsound.pinned-initto be unsound. rust-lang/rust#153535.pin-init): replace shadowed return token byunsafe-to-create token pin-init#117.Nice to have (not critical, we could workaround if needed, etc.)
A way to easily export in the prelude macros generated by macros.
#[macro_export] macro_rulesrust-lang/rust#52234.-masm=equivalent (i.e. the ability to configure the assembly syntax default).asm!blocks will needoptions(att_syntax).asm!with the option set should be fairly straightforward (Experimental tracepoint support #1084 (comment)).options(intel_syntax)in the other case).Support in
asm!for several string literals.core::arch::asm!("" "");.#defines to reuse assembly in both C and Rust (RSCPPKbuild rule), and GCC/Clang allow e.g.asm("" "");, thus it is easiest if Rust'sasm!allows it as well.::kernel::concat_literals!(...).Amanieu says:
#[may_dangle].Arc, the same abilities as the standard library's.#[may_dangle], a refined dropck escape hatch (tracking issue for RFC 1327) rust-lang/rust#34761.Extern types (
extern { type S; }).Opaque<T>:Opaque<T>carries aT(it isMaybeUninit+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. callingmem::swapon them.bindgencould also use the functionality instead of the current recommended workaround in its generated code. In addition,bindgencould 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.extern typecannot supportsize_of_valandalign_of_valrust-lang/rust#49708.Support more than just integer literals (e.g.
const) in attributes likerepr(align(...)).const PAGE_SIZE: usize = 4096;frombindgen, and ideally we would be able to do#[repr(align(PAGE_SIZE))] struct S;.Leveraging the same magic
Boxhas.allocmodule with our ownKBox,KVecetc.Pattern types (ranges, bounded integers, type constraints...).
Alignmentand genericPowerOfTwo.Attributes on expressions.
A solution for the
dma_read!soundness issue.rustc'sdangerous_implicit_autorefslint 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:offset_of_val!): https://internals.rust-lang.org/t/offset-of-val/23977.Items only public for a given macro.
Discussion needed
Will
&mut Tbe always treated as*mut Tfor!Unpintypes?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...-Cpanic=abort.-Coverflow-checks=report(allowing to customize the handler)".unwrapClippy lints): https://lore.kernel.org/rust-for-linux/CANiq72nJiJ4K6jy17x-YRYnJpjqTnohYWvoFrLkYQp0X4tLL=w@mail.gmail.com/Disabling particular unsafe precondition checks under
-Cdebug-assertions=y.The kernel is always compiled with high levels of optimizations (currently either
-O2or-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=ywill always check all unsafe preconditions, without a way to opt-out for particular cases (e.g. previously one could write aunreachable_uncheckedfor a fallible API even if theuncheckedversion of the API had adebug_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 forfeature(cfg_ub_checks)and-Zub-checksrust-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=yrust-lang/rust#120969 (comment):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=yrust-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.
Communication between the Rust and C (LKMM) memory models.
memcpy:A solution for updating the kernel (e.g. fixing a bug in
core) without forcing recompilation of loadable/out-of-tree Rust modules.#[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).#[export](dynamically linked crates) rust-lang/rfcs#3435 together with Tracking Issue for the experimentalcrabiABI rust-lang/rust#111423. See [2025H1] Research: How to achieve safety when linking separately compiled code rust-lang/rust-project-goals#155 as well.A solution for getting unique/stable function pointers to "generic callbacks" like
devres_callback<T>().Improved C interop/support.
bindgen/cbindgensupport, accepting GNU/Clang-like flags, etc.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/rust-project-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
fundamentalfeature 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.
#[cfg(CONFIG_RUSTC_VERSION >= 107900)].rustcversion cases,#[cfg(version(...))]or#[cfg(accessible(...))]may be alternatives (cfg(version(...))was finally decided to returntruewhen matching against nightly (by default, i.e. unless-Zassume-incomplete-releaseis given), which is generally what we want, since we would expect developers to use the latest nightlies only).#[cfg(version(..))]rust-lang/rust#64796.#[cfg(accessible(::path::to::thing))]rust-lang/rust#64797.#[cfg(version(...))]rust-lang/rust#141137.cfgs on the fly for each condition/feature/etc. via Kconfig, which is also a more flexible in general.A better way to handle
cfgconditionals, such as the upcomingcfg_select!upstream.cfg_select(formerlycfg_match) rust-lang/rust#115585.if_cfg!macro #1183.cfg_select!rust-lang/rust#149783.Safe transmute.
zerocopy.fn_cast!-- could that be made safe for certain subsets of casts?Enough specialization to improve the performance of our
alloc(feature(min_specialization)).Arc.specializationis unsound,min_specializationmay be sound. We would only want to allow it forArc, rather than subsystems in general. Nevertheless, it is very tricky to use properly at the time ("evenrustcdevs mess up withmin_specialization."). In addition, there are bugs remaining, e.g. just enablingmin_specializationis 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
consttraits.Partial initialization of locals (
feature(partial_init_locals)).partial_init_localsrust-lang/rust#153699.Low priority (we will likely not use them in the end)
A way to elegantly handle "noop conditional compilation wrappers".
!CONFIG_PRINTK#669.quoteas part of the freestanding standard library.quote!macro inproc_macrorust-lang/rust#54722.synas part of the freestanding standard library.Done (stabilized, fixed, not needed anymore, etc.)
Remove the need for defining
__rust_*methods.GlobalAlloc-related symbols are generated #68.feature(let_else).feature(const_refs_to_static)&feature(const_refs_to_static).feature(lint_reasons).Inline assembly:
asm gotosupport (feature(asm_goto)).Allow
#[repr(Rust)].#[no_mangle]for non-repr(C)pub statics rust-lang/rust-clippy#11219 (see Clippy's list).#[repr(Rust)]rust-lang/rust#114201 (1.74).assume-like mechanism (core::hint::assert_unchecked).hint::assert_uncheckedrust-lang/rust#119131.hint::assert_uncheckedrust-lang/rust#123588 (1.81).Make
unsafe_op_in_unsafe_fnthe default dialect in a future edition.unsafe_op_in_unsafe_fnto bewarn-by-default from edition 2024 rust-lang/rust#112038.unsafe_op_in_unsafe_fnrust-lang/rust#112017.Naked functions.
naked_functionsrust-lang/rust#134213 (1.88).likely/unlikely-like mechanism.Field projections (
feature(field_projections)).