Re: [PATCH v6 9/9] rust: sync: atomic: Add Atomic<{usize,isize}>
Miguel Ojeda <[email protected]> Fri, 11 Jul 2025 15:45:32 +0200
| Newsgroups | dev.linux.lists.lkmm,org.kernel.vger.linux-arch,org.kernel.vger.linux-kernel,org.kernel.vger.rust-for-linux |
|---|---|
| Message-ID | <CANiq72m9AeqFKHrRniQ5Nr9vPv2MmUMHFTuuj5ydmqo+OYn60A@mail.gmail.com> |
On Fri, Jul 11, 2025 at 11:00 AM Benno Lossin <[email protected]> wrote: > > Do we have a static assert with these cfgs that `isize` has the same > size as these? > > If not, then it would probably make sense to add them now. Yeah, according to e.g. Matthew et al., we may end up with 128-bit pointers in the kernel fairly soon (e.g. a decade): https://lwn.net/Articles/908026/ I rescued part of what I wrote in the old `mod assumptions` which I never got to send back then -- most of the `static_asserts` are redundant now that we define directly the types in the `ffi` crate (I mean, we could still assert that `size_of::<c_char>() == 1` and so on, but they are essentially a tautology now), so I adapted the comments. Please see below (draft). Cheers, Miguel
0001-rust-ffi-assert-sizes-and-clarify-128-bit-situation.patch
(text/x-patch, 2 KB)
From afd58f3808bd41cfb92bf1acdf2a19081a439ca3 Mon Sep 17 00:00:00 2001 From: Miguel Ojeda <[email protected]> Date: Fri, 11 Jul 2025 15:27:27 +0200 Subject: [PATCH] rust: ffi: assert sizes and clarify 128-bit situation Link: https://lwn.net/Articles/908026/ Signed-off-by: Miguel Ojeda <[email protected]> --- rust/ffi.rs | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/rust/ffi.rs b/rust/ffi.rs index d60aad792af4..bbda56c28ca8 100644 --- a/rust/ffi.rs +++ b/rust/ffi.rs @@ -38,11 +38,43 @@ macro_rules! alias { // In the kernel, `intptr_t` is defined to be `long` in all platforms, so we can map the type to // `isize`. + // + // It is likely that the assumption that `long` is the size of a CPU register/pointer will stay + // when support for 128-bit architectures is added, thus these will still mapped to `{i,u}size`. c_long = isize; c_ulong = usize; + // Since `long` will likely be 128-bit for 128-bit architectures, `long long` will likely be + // increased. Thus these may happen to be either 64-bit or 128-bit in the future, and thus new + // code should avoid relying on them being 64-bit. c_longlong = i64; c_ulonglong = u64; } +// Thus, `long` may be 32-bit, 64-bit or 128-bit. +const _: () = { + assert!( + core::mem::size_of::<c_long>() + == if cfg!(CONFIG_128BIT) { + core::mem::size_of::<u128>() + } else if cfg!(CONFIG_64BIT) { + core::mem::size_of::<u64>() + } else { + core::mem::size_of::<u32>() + } + ); +}; + +// And `long long` may be 64-bit or 128-bit. +const _: () = { + assert!( + core::mem::size_of::<c_longlong>() + == if cfg!(CONFIG_64BIT) { + core::mem::size_of::<u64>() + } else { + core::mem::size_of::<u128>() + } + ); +}; + pub use core::ffi::c_void; base-commit: d7b8f8e20813f0179d8ef519541a3527e7661d3a -- 2.50.1