`core` wanted features & bugfixes

[ojeda]

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

Features that we would like to see

Required (we almost certainly want them)

• Disabling atomics (i.e. only allowing the LKMM ones introduced in v6.18 in the kernel crate).

  • Part of the "modularization of core" topic.

• Guaranteeing TypeId's size is at most 16 bytes.

  • PR: library: core: document layout guarantee of TypeId rust-lang/rust#148265.
  • Meeting Proposal: Document layout guarantee of TypeId rust-lang/compiler-team#941.
  • Zulip: https://rust-lang.zulipchat.com/#narrow/channel/425075-rust-for-linux/topic/TypeId.20layout.
  • Zulip: https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/TypeID.20design.

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

• Disabling 128-bit features.

  • Part of the "modularization of core" topic.
  • PR: Add cfg(no_128_bit) to core: removes u128/i128 formatting rust-lang/rust#103126.
  • PR: WIP/ POC Add no_iu128_fmt config to disable 128 bit integer formatting. rust-lang/rust#136385.

• Disabling floating-point features.

  • Part of the "modularization of core" topic.
  • Currently we provide weak symbols that panics, but generally we should not even compile floating point support (in the kernel, very little code needs it, and it is compiled differently in the C side). Ideally, we would have a compiler flag to disable all that where not needed (possibly even not accepting code referring to f32 etc.).

    Maybe we should add a check, perhaps by compiling against softfp and link against compile-rt with hardfp to see if no symbols are unresolved?

  • Cc: @nbdd0121.
  • PR (a cfg to disable formatting of floating point): core: add unstable no_fp_fmt_parse to disable float formatting code rust-lang/rust#86048.

• Disabling Unicode features / a way to use external tables.

  • Part of the "modularization of core" topic.

• Clarify invariants of the Layout type.

  • i.e. lift requirements to the type from the constructors / how does one connect Layout to "a layout suitable to an allocated object"? Is it library / language UB? (currently it appears to be the former).
  • After [ptr] Document maximum allocation size rust-lang/rust#116675, a reference could be added to that from Layout type documentation.
  • Rust Zulip: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Document.20.60Layout.60.20Type.20Invariant.3F/near/412607198.
  • From: discussion in Rust for Linux Zulip between Valentin, Benno and Miguel.
  • Related issue in UCG: Where to document allocation size upper bound? rust-lang/unsafe-code-guidelines#465.
  • Related PR: Enforce that layout size fits in isize in Layout rust-lang/rust#95295.

• c_stringify!, c_concat!, c_file! macros.

  • Instead of having to provide a c_str! macro to then do c_str!(stringify!(...)) or c_str!(concat!(...)).
  • Lore: https://lore.kernel.org/rust-for-linux/CANiq72nbbtNp4vGGHkXVSgSW+WU=5Z9uGRO_LLg7+ezTqrZ_tQ@mail.gmail.com/
  • Rust Zulip: https://rust-lang.zulipchat.com/#narrow/stream/404510-wg-macros/topic/May.20we.20need.20a.20.60c_stringify!.60.20and.20.60c_concat!.60.20macros.3F/near/466691443.
  • Cc: @vincenzopalazzo @y86-dev.
  • It could prevent mistakes where one assumes it is nul-terminated, perhaps disallowing the usual one in Clippy: https://lore.kernel.org/rust-for-linux/20241016035214.2229-8-fujita.tomonori@gmail.com/#iZ31rust:kernel:io:poll.rs.

• Clarify addr_of! documentation about whether it creates read-only pointers or not.

  • From: Allow to run unit tests using KUnit with a user-space like syntax #950 (comment).
  • PR: clarify that addr_of creates read-only pointers rust-lang/rust#129653.

• Moving towards core::ffi::CStr (from kernel::str::CStr).

  • Rust for Linux Issue: Replace kernel::str::CStr by core::ffi::CStr #1075.
  • PR: Implement Deref<Target=ByteStr> for CStr rust-lang/rust#138498.
  • impl Display for CStr ACP: impl Display for CStr rust-lang/libs-team#550.
  • impl Display for CStr Tracking Issue: Tracking Issue for CStr::display rust-lang/rust#139984.
  • impl Display for CStr PR: add CStr::display rust-lang/rust#139994.
  • ByteStr Tracking Issue: Tracking Issue for ByteStr/ByteString rust-lang/rust#134915.
  • Related PR: Improve the documentation of Display and FromStr, and their interactions rust-lang/rust#136687.
  • Lore ("rust: replace kernel::str::CStr w/ core::ffi::CStr"): https://lore.kernel.org/rust-for-linux/20250317-cstr-core-v9-0-51d6cc522f62@gmail.com/.
  • Lore (Gary's suggestion): https://lore.kernel.org/all/20250221142816.0c015e9f@eugeo/.

• container_of! in the standard library.

  • Currently we use our own implementation.

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

• Generic atomics.
  • We are considering whether to use a generic API for our atomics, thus we will be watching any progress on the core ones.
  • Issue: Tracking Issue for generic Atomic rust-lang/rust#130539.
  • ACP (API Change Proposal): ACP: Generic Atomic<T> rust-lang/libs-team#443.
  • Initial PR: Create Atomic<T> type alias rust-lang/rust#130543.
  • PR: Create Atomic<T> type alias (rebase) rust-lang/rust#136316 (1.88).
  • LPC Rust MC topic: https://lpc.events/event/18/contributions/1788/
  • Cc: @fbq.

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

• Ensure no_fp_fmt_parse builds are warning-free.

  • PR: core: ensure no_fp_fmt_parse builds are warning-free rust-lang/rust#105811.

• Ensure no_global_oom_handling builds are warning-free.

  • PR: Add test for warning-free builds of core under no_global_oom_handling rust-lang/rust#110652.

• C string equivalents (nul-terminated) for core::panic::Location (or a flag to ensure there is a \0 after the strs).

  • Moved to the main list: feature(location_file_nul).
  • Tracking Issue: Tracking Issue for NUL-terminated file names with #[track_caller] rust-lang/rust#141727.
  • For the macros like file!(), it is fine, since we can easily transform those with c_str! (which we already do), so it is a nice to have (see the related item below).
  • Lore: https://lore.kernel.org/rust-for-linux/CAH5fLgjk5koTwMOcdsnQjTVWQehjCDPoD2M3KboGZsxigKdMfA@mail.gmail.com/.
  • Rust Zulip: https://rust-lang.zulipchat.com/#narrow/stream/425075-rust-for-linux/topic/Caller.20location.20with.20nul-terminated.20filename/near/477164522.
  • ACP: ACP: Add nul-terminated version of core::panic::Location::file rust-lang/libs-team#466 (accepted).
  • PR: Add Location::file_with_nul rust-lang/rust#135054 (1.89).
  • PR: Add unstable option to nul-terminate location strings rust-lang/rust#135240.
  • PR: Add nul-terminated filename for #[track_caller] rust-lang/rust#131828.
  • PR: Null terminate core::panic::Location file strings rust-lang/rust#117431.

• feature(int_lowest_highest_one), i.e. {highest,lowest_one} ({first,last}_set_bit) for integer types.

  • Moved to the main list: feature(int_lowest_highest_one).
  • Tracking Issue: Tracking Issue for int_lowest_highest_one rust-lang/rust#145203.
  • PR: Implement feature int_lowest_highest_one for integer and NonZero types rust-lang/rust#145381 (1.91).
  • ACP (API Change Proposal): first_set_bit and last_set_bit for integer types rust-lang/libs-team#631.
  • Lore: https://lore.kernel.org/rust-for-linux/DAREXAUV51B6.7X7TPOJKK249@nvidia.com/.
  • Cc: @Gnurou.

---

Bugs that we would like to see fixed

Required (we almost certainly want them)

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

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

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

• Fix warning when libcore is compiled with no_fp_fmt_parse rust-lang/rust#105434.

• Fix no_global_oom_handling build.

  • PR: Fix no_global_oom_handling build rust-lang/rust#110649.

• Inline floating-point methods to avoid requiring intrinsics.

  • midpoint, next_up, next_down are not marked as #[inline], which makes them appear under -Os arm64, see Zulip: https://rust-for-linux.zulipchat.com/#narrow/stream/288089-General/topic/v6.2E11-rc1.20doesn't.20build.20for.20arm64/near/455637364.
  • PR: Mark {f32,f64}::{next_up,next_down,midpoint} inline rust-lang/rust#128749.

• CFI failure on core::fmt::write() when FineIBT is enabled.

  • Issue: CFI: core and std have explict CFI violations rust-lang/rust#115199.
  • PR (point 2 of the issue above): cfi: do not transmute function pointers in formatting code rust-lang/rust#139632 (1.88).
  • PR (previous approach): cfi: Store type erasure witness for Argument rust-lang/rust#115954.
  • Patch to restrict FineIBT with Rust: https://lore.kernel.org/rust-for-linux/20250410115420.366349-1-panikiel@google.com/.

[bjorn3]

Disabling futures features.

I could only find a single function that is neither generic nor #[inline] for the future handling. This function is very small, so disabling futures in libcore will barely save any space. Generic and #[inline] functions are only codegened when actually used. All disabling futures will do is prevent someone from deliberately using futures and possibly for the current rustc version cause an ICE when trying to use async fn. (haven't checked though)

[fbq]

Disabling futures features.

All disabling futures will do is prevent someone from deliberately using futures and possibly for the current rustc version cause an ICE when trying to use async fn. (haven't checked though)

Right! I'm experimenting implementing two Contexts backed by the mechanisms of Linux kernel to poll Futures:

• A kernel thread, Future polled in thread functions and wake means wake up a kernel thread. (I already have a working version)
• A work item in workqueue, Future polled in work functions and wake means requeue the work item in the workqueue. (Still need to figure out some safe abstraction, but it works in theory).

Future may help kernel developers to refactor (rethink) some async work, so I think it's very important that we support it.

[ojeda]

I could only find a single function that is neither generic nor #[inline] for the future handling. This function is very small, so disabling futures in libcore will barely save any space. Generic and #[inline] functions are only codegened when actually used. All disabling futures will do is prevent someone from deliberately using futures and possibly for the current rustc version cause an ICE when trying to use async fn. (haven't checked though)

This came from the original list I had in the other issue, where they were examples of the general idea of partitioning core. I agree that it does not make much sense to list it now that they are split as actual items we would like. Removed!

[GKFX]

I have opened a PR to remove 128-bit features: rust-lang/rust#103126.

[ojeda]

Thanks! Added.

[workingjubilee]

Before we add more cfg, if the goal is mostly a smaller text size, then can we look at just... trying to optimize the actual sizes of things? rust-lang/rust#109216 got a win of ~24KiB in size (and faster, mostly!) by taking a swing at that.

Adding configuration code doesn't necessarily affect statically linked binaries as much, as those will either be stuck with the code also, for each that actually uses it, or dead-code-eliminate it, and statically linked binaries include some of the use-cases that want the smallest size (such as embedded code which isn't running on an OS at all, not even an RTOS, and thus has limited options for dynamic linking and is usually just one blobby image).

[tgross35]

This may come in handy at some point down the line https://github.com/Amanieu/rfcs/blob/core-detect/text/0000-core_detect.md

[fbq]

Following up the discussion here, I'd like to add two asm wanted features:

• asm goto (or jump to a label), this is required by the static key
• memory operand, this would allow generate more efficient code, and it's currently supported by inline asm of gcc and clang, and used by Linux kernel.

Although @nbdd0121 mentioned these should be lang feature instead of core feature. But I haven't found a lang feature issue. Feel free to put it wherever you see fit ;-)

[ojeda]

Sounds good, thanks! Language features are in #354 (I had asm goto there already, added memory operands too now).

[BennoLossin]

@ojeda about the c_stringify! macro, we should probably ask the libs team, since that would be their area.

[ojeda]

+1, I think @vincenzopalazzo wanted to mention it to the macros working group too.