From: Boqun Feng <boqun.feng@gmail.com>
To: Benno Lossin <lossin@kernel.org>
Cc: linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
lkmm@lists.linux.dev, linux-arch@vger.kernel.org,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>,
"Will Deacon" <will@kernel.org>,
"Peter Zijlstra" <peterz@infradead.org>,
"Mark Rutland" <mark.rutland@arm.com>,
"Wedson Almeida Filho" <wedsonaf@gmail.com>,
"Viresh Kumar" <viresh.kumar@linaro.org>,
"Lyude Paul" <lyude@redhat.com>, "Ingo Molnar" <mingo@kernel.org>,
"Mitchell Levy" <levymitchell0@gmail.com>,
"Paul E. McKenney" <paulmck@kernel.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Linus Torvalds" <torvalds@linux-foundation.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Alan Stern" <stern@rowland.harvard.edu>
Subject: Re: [PATCH v7 2/9] rust: sync: Add basic atomic operation mapping framework
Date: Mon, 14 Jul 2025 06:42:57 -0700 [thread overview]
Message-ID: <aHUJYTv4_wsatAw5@Mac.home> (raw)
In-Reply-To: <DBBOXLF23VVA.2T3U6GBOZ3Y20@kernel.org>
On Mon, Jul 14, 2025 at 12:03:11PM +0200, Benno Lossin wrote:
[...]
> > +declare_and_impl_atomic_methods!(
> > + /// Basic atomic operations
> > + pub trait AtomicHasBasicOps {
>
> I think we should drop the `Has` from the names. So this one can just be
> `AtomicBasicOps`. Or how about `BasicAtomic`, or `AtomicBase`?
>
Actually, given your feedback to `ordering::Any` vs `core::any::Any`,
I think it makes more sense to keep the current names ;-) These are only
trait names to describe what operations do an `AtomicImpl` has, and they
should be used only in atomic mod, so naming them a bit longer is not a
problem. And by doing so, we free the better names `BasicAtomic` or
`AtomicBase` for other future usages.
Best I could do is `AtomicBasicOps` or `HasAtomicBasicOps`.
> > + /// Atomic read (load).
> > + ///
> > + /// # Safety
> > + /// - `ptr` is aligned to [`align_of::<Self>()`].
> > + /// - `ptr` is valid for reads.
> > + ///
> > + /// [`align_of::<Self>()`]: core::mem::align_of
> > + unsafe fn read[acquire](ptr: *mut Self) -> Self {
> > + bindings::#call(ptr.cast())
> > + }
> > +
> > + /// Atomic set (store).
> > + ///
> > + /// # Safety
> > + /// - `ptr` is aligned to [`align_of::<Self>()`].
> > + /// - `ptr` is valid for writes.
> > + ///
> > + /// [`align_of::<Self>()`]: core::mem::align_of
> > + unsafe fn set[release](ptr: *mut Self, v: Self) {
> > + bindings::#call(ptr.cast(), v)
> > + }
> > + }
> > +);
> > +
> > +declare_and_impl_atomic_methods!(
> > + /// Exchange and compare-and-exchange atomic operations
> > + pub trait AtomicHasXchgOps {
>
> Same here `AtomicXchgOps` or `AtomicExchangeOps` or `AtomicExchange`?
> (I would prefer to not abbreviate it to `Xchg`)
>
The "Xchg" -> "Exchange" part seems fine to me.
> > + /// Atomic exchange.
> > + ///
> > + /// Atomically updates `*ptr` to `v` and returns the old value.
> > + ///
> > + /// # Safety
> > + /// - `ptr` is aligned to [`align_of::<Self>()`].
> > + /// - `ptr` is valid for reads and writes.
> > + ///
> > + /// [`align_of::<Self>()`]: core::mem::align_of
> > + unsafe fn xchg[acquire, release, relaxed](ptr: *mut Self, v: Self) -> Self {
> > + bindings::#call(ptr.cast(), v)
> > + }
> > +
> > + /// Atomic compare and exchange.
> > + ///
> > + /// If `*ptr` == `*old`, atomically updates `*ptr` to `new`. Otherwise, `*ptr` is not
> > + /// modified, `*old` is updated to the current value of `*ptr`.
> > + ///
> > + /// Return `true` if the update of `*ptr` occured, `false` otherwise.
> > + ///
> > + /// # Safety
> > + /// - `ptr` is aligned to [`align_of::<Self>()`].
> > + /// - `ptr` is valid for reads and writes.
> > + /// - `old` is aligned to [`align_of::<Self>()`].
> > + /// - `old` is valid for reads and writes.
> > + ///
> > + /// [`align_of::<Self>()`]: core::mem::align_of
> > + unsafe fn try_cmpxchg[acquire, release, relaxed](ptr: *mut Self, old: *mut Self, new: Self) -> bool {
> > + bindings::#call(ptr.cast(), old, new)
> > + )}
> > + }
> > +);
> > +
> > +declare_and_impl_atomic_methods!(
> > + /// Atomic arithmetic operations
> > + pub trait AtomicHasArithmeticOps {
>
> Forgot to rename this one to `Add`? I think `AtomicAdd` sounds best for
No, because at the `AtomicImpl` level, it's easy to know whether a type
has all the arithmetic operations or none (also the `Delta` type should
be known). But I don't have opinions on renaming it to `AtomicAddOps` or
`HasAtomicAddOps`.
Regards,
Boqun
> this one.
>
> ---
> Cheers,
> Benno
>
> > + /// Atomic add (wrapping).
> > + ///
> > + /// Atomically updates `*ptr` to `(*ptr).wrapping_add(v)`.
> > + ///
> > + /// # Safety
> > + /// - `ptr` is aligned to `align_of::<Self>()`.
> > + /// - `ptr` is valid for reads and writes.
> > + ///
> > + /// [`align_of::<Self>()`]: core::mem::align_of
> > + unsafe fn add[](ptr: *mut Self, v: Self::Delta) {
> > + bindings::#call(v, ptr.cast())
> > + }
> > +
> > + /// Atomic fetch and add (wrapping).
> > + ///
> > + /// Atomically updates `*ptr` to `(*ptr).wrapping_add(v)`, and returns the value of `*ptr`
> > + /// before the update.
> > + ///
> > + /// # Safety
> > + /// - `ptr` is aligned to `align_of::<Self>()`.
> > + /// - `ptr` is valid for reads and writes.
> > + ///
> > + /// [`align_of::<Self>()`]: core::mem::align_of
> > + unsafe fn fetch_add[acquire, release, relaxed](ptr: *mut Self, v: Self::Delta) -> Self {
> > + bindings::#call(v, ptr.cast())
> > + }
> > + }
> > +);
>
next prev parent reply other threads:[~2025-07-14 13:43 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-14 5:36 [PATCH v7 0/9] LKMM generic atomics in Rust Boqun Feng
2025-07-14 5:36 ` [PATCH v7 1/9] rust: Introduce atomic API helpers Boqun Feng
2025-07-16 9:23 ` Greg Kroah-Hartman
2025-07-16 12:36 ` Miguel Ojeda
2025-07-16 12:47 ` Peter Zijlstra
2025-07-16 12:54 ` Greg Kroah-Hartman
2025-07-16 12:57 ` Miguel Ojeda
2025-07-16 13:04 ` Peter Zijlstra
2025-07-16 12:56 ` Miguel Ojeda
2025-07-14 5:36 ` [PATCH v7 2/9] rust: sync: Add basic atomic operation mapping framework Boqun Feng
2025-07-14 10:03 ` Benno Lossin
2025-07-14 13:42 ` Boqun Feng [this message]
2025-07-14 15:00 ` Benno Lossin
2025-07-14 15:34 ` Boqun Feng
2025-07-14 5:36 ` [PATCH v7 3/9] rust: sync: atomic: Add ordering annotation types Boqun Feng
2025-07-14 10:10 ` Benno Lossin
2025-07-14 14:59 ` Boqun Feng
2025-07-14 15:16 ` Benno Lossin
2025-07-14 5:36 ` [PATCH v7 4/9] rust: sync: atomic: Add generic atomics Boqun Feng
2025-07-14 10:30 ` Benno Lossin
2025-07-14 14:21 ` Boqun Feng
2025-07-14 14:30 ` Boqun Feng
2025-07-14 14:34 ` Miguel Ojeda
2025-07-14 14:53 ` Boqun Feng
2025-07-14 15:16 ` Benno Lossin
2025-07-14 15:05 ` Benno Lossin
2025-07-14 15:32 ` Boqun Feng
2025-07-15 9:36 ` Benno Lossin
2025-07-15 13:14 ` Boqun Feng
2025-07-15 15:35 ` Benno Lossin
2025-07-14 5:36 ` [PATCH v7 5/9] rust: sync: atomic: Add atomic {cmp,}xchg operations Boqun Feng
2025-07-14 10:56 ` Benno Lossin
2025-07-14 5:36 ` [PATCH v7 6/9] rust: sync: atomic: Add the framework of arithmetic operations Boqun Feng
2025-07-15 11:21 ` Benno Lossin
2025-07-15 13:33 ` Boqun Feng
2025-07-15 15:45 ` Benno Lossin
2025-07-15 16:13 ` Boqun Feng
2025-07-15 18:39 ` Benno Lossin
2025-07-15 20:13 ` Boqun Feng
2025-07-16 10:25 ` Benno Lossin
2025-07-16 14:13 ` Boqun Feng
2025-07-16 15:36 ` Benno Lossin
2025-07-16 15:48 ` Boqun Feng
2025-07-16 17:16 ` Benno Lossin
2025-07-16 17:38 ` Boqun Feng
2025-07-14 5:36 ` [PATCH v7 7/9] rust: sync: atomic: Add Atomic<u{32,64}> Boqun Feng
2025-07-14 5:36 ` [PATCH v7 8/9] rust: sync: Add memory barriers Boqun Feng
2025-07-14 5:36 ` [PATCH v7 9/9] rust: sync: atomic: Add Atomic<{usize,isize}> Boqun Feng
2025-07-14 11:06 ` Benno Lossin
2025-07-14 13:47 ` Boqun Feng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aHUJYTv4_wsatAw5@Mac.home \
--to=boqun.feng@gmail.com \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=dakr@kernel.org \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=levymitchell0@gmail.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkmm@lists.linux.dev \
--cc=lossin@kernel.org \
--cc=lyude@redhat.com \
--cc=mark.rutland@arm.com \
--cc=mingo@kernel.org \
--cc=ojeda@kernel.org \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=tglx@linutronix.de \
--cc=tmgross@umich.edu \
--cc=torvalds@linux-foundation.org \
--cc=viresh.kumar@linaro.org \
--cc=wedsonaf@gmail.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.