On Fri, Apr 24, 2026, at 11:43, Link Mauve wrote:
On Fri, Apr 24, 2026 at 10:14:25AM +0100, David Laight wrote:
On Fri, 24 Apr 2026 11:17:40 +0530 "Mukesh Kumar Chaurasiya (IBM)" mkchauras@gmail.com wrote:
From: Link Mauve linkmauve@linkmauve.fr
The core crate currently depends on these two functions for i64/u64/ i128/u128/core::time::Duration formatting, but we shouldn’t use that in the kernel so let’s panic if they are ever called.
Ugg. Surely you can make it a link-time failure? Or change the underlying code to avoid the divide.
This is currently a link-time failure, which means if any of the core crate or drm_panic_qr are linked in, the kernel will fail to link.
And since we rely on core, that means no kernel can be built on PowerPC without this patch.
A possible solution would be to change the core crate to not divide u64s, but the last time I tried to do that I couldn’t quite figure out how to do formatting without it, maybe I will just open an issue against Rust.
How hard would it be to have a private copy of the parts of the core crate that the kernel actually needs? Since Linux is neither quite hosted (using a full libc) nor entirely freestanding (still using some library interfaces), the C implementation on most architectures has a small subset of the libgcc that we ship with the kernel.
I assume the core crate is larger than libgcc, but I don't know how much of it is actually needed here.
Arnd
On Fri, Apr 24, 2026 at 12:21 PM Arnd Bergmann arnd@arndb.de wrote:
How hard would it be to have a private copy of the parts of the core crate that the kernel actually needs? Since Linux is neither quite hosted (using a full libc) nor entirely freestanding (still using some library interfaces), the C implementation on most architectures has a small subset of the libgcc that we ship with the kernel.
I assume the core crate is larger than libgcc, but I don't know how much of it is actually needed here.
It is fairly tied to the compiler version, so it would be a substantial effort to support across a bunch of versions. Instead of that, initially we asked to have some `cfg`s (i.e. conditional compilation) to customize it in the few places we need. We already pass `--cfg no_fp_fmt_parse` for instance.
There were concerns about combinatorial explosion of `cfg`s, so we suggested `cfg(linux_kernel)` or similar instead, though nothing happened so far.
The other option is to at least lint against certain operations, but I think it would be better to have a way to tell the compiler we really don't want them generated to begin with.
Cheers, Miguel
linaro-mm-sig@lists.linaro.org
-
Arnd Bergmann -
Miguel Ojeda