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)

• C string equivalents (nul-terminated) for core::panic::Location.
  • For the macros like file!(), it is fine, since we can easily transform those with c_str! (which we already do).
  • 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.
  • PR: Add nul-terminated filename for #[track_caller] rust-lang/rust#131828.
  • PR: Null terminate core::panic::Location file strings rust-lang/rust#117431.

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

• Disabling 128-bit features.

  • PR: Add cfg(no_128_bit) to core: removes u128/i128 formatting rust-lang/rust#103126.

• Disabling floating-point features.

  • 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.

• 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/[email protected]/#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.

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.
  • 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.

---

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.

[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).

[y86-dev]

@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.

[tgross35]

In theory the new macro metavar expression ${concat(c, $str)} might be able to handle it where needed.

[vincenzopalazzo]

I finally had the time to start discussing the c_stringify! on the wg-macros, if you would like to follow it, please see the zulip discussion

[ojeda]

Thanks! Added.