Re: [PATCH v8 4/9] rust: sync: atomic: Add generic atomics
"Benno Lossin" <[email protected]> Tue, 12 Aug 2025 09:59:39 +0200
| Newsgroups | dev.linux.lists.lkmm,org.kernel.vger.linux-arch,org.kernel.vger.linux-kernel,org.kernel.vger.rust-for-linux |
|---|---|
| Message-ID | <[email protected]> |
On Sat Jul 19, 2025 at 5:08 AM CEST, Boqun Feng wrote: > To provide using LKMM atomics for Rust code, a generic `Atomic<T>` is > added, currently `T` needs to be Send + Copy because these are the > straightforward usages and all basic types support this. > > Implement `AtomicType` for `i32` and `i64`, and so far only basic > operations load() and store() are introduced. > > Reviewed-by: Alice Ryhl <[email protected]> > Signed-off-by: Boqun Feng <[email protected]> Reviewed-by: Benno Lossin <[email protected]> > --- > rust/kernel/sync/atomic.rs | 274 +++++++++++++++++++++++++++ > rust/kernel/sync/atomic/predefine.rs | 15 ++ > 2 files changed, 289 insertions(+) > create mode 100644 rust/kernel/sync/atomic/predefine.rs > +/// # Limitations > +/// > +/// Because C primitives are used to implement the atomic operations, and a C function requires a > +/// valid object of a type to operate on (i.e. no `MaybeUninit<_>`), hence at the Rust <-> C > +/// surface, only types with all the bits initialized can be passed. As a result, types like `(u8, > +/// u16)` (padding bytes are uninitialized) are currently not supported. Note that technically > +/// these types can be supported if some APIs are removed for them and the inner implementation is > +/// tweaked, but the justification of support such a type is not strong enough at the moment. This > +/// should be resolved if there is an implementation for `MaybeUninit<i32>` as `AtomicImpl`. I'd remove the last sentence, as it makes it sound like one only would have to add that impl and be finished. --- Cheers, Benno