Re: [PATCH v6 6/9] rust: sync: atomic: Add the framework of arithmetic operations
Boqun Feng <[email protected]> Fri, 11 Jul 2025 10:41:20 -0700
| 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 Fri, Jul 11, 2025 at 07:39:15AM -0700, Boqun Feng wrote:
[...]
> > > ---
> > > rust/kernel/sync/atomic.rs | 18 +++++
> > > rust/kernel/sync/atomic/generic.rs | 108 +++++++++++++++++++++++++++++
> > > 2 files changed, 126 insertions(+)
> >
> > I think it's better to name this trait `AtomicAdd` and make it generic:
> >
> > pub unsafe trait AtomicAdd<Rhs = Self>: AllowAtomic {
> > fn rhs_into_repr(rhs: Rhs) -> Self::Repr;
> > }
> >
> > `sub` and `fetch_sub` can be added using a similar trait.
> >
>
> Seems a good idea, I will see what I can do. Thanks!
>
> > The generic allows you to implement it multiple times with different
> > meanings, for example:
> >
> > pub struct Nanos(u64);
> > pub struct Micros(u64);
> > pub struct Millis(u64);
> >
> > impl AllowAtomic for Nanos {
> > type Repr = i64;
> > }
> >
> > impl AtomicAdd<Millis> for Nanos {
> > fn rhs_into_repr(rhs: Millis) -> i64 {
> > transmute(rhs.0 * 1000_000)
>
> We probably want to use `as` in real code?
>
> > }
> > }
> >
> > impl AtomicAdd<Micros> for Nanos {
> > fn rhs_into_repr(rhs: Micros) -> i64 {
> > transmute(rhs.0 * 1000)
> > }
> > }
> >
> > impl AtomicAdd<Nanos> for Nanos {
> > fn rhs_into_repr(rhs: Nanos) -> i64 {
> > transmute(rhs.0)
> > }
> > }
> >
> > For the safety requirement on the `AtomicAdd` trait, we might just
> > require bi-directional transmutability... Or can you imagine a case
> > where that is not guaranteed, but a weaker form is?
>
> I have a case that I don't think it's that useful, but it's similar to
> the `Micros` and `Millis` above, an `Even<T>` where `Even<i32>` is a
Oh I mis-read, it's not similar to `Micros` or `Millis`, but still,
`Even<i32>` itself should have the point.
> `i32` but it's always an even number ;-) So transmute<i32, Even<i32>>()
> is not always sound. Maybe we could add a "TODO" in the safety section
> of `AtomicAdd`, and revisit this later? Like:
>
> /// (in # Safety)
> /// TODO: The safety requirement may be tightened to bi-directional
> /// transmutability.
>
> And maybe also add the `Even` example there?
>
> Thoughts?
>
Or since we are going to use fine-grained traits, it's actually easy to
define the safety requirement of `AtomicAdd` (instead of
`AllowAtomicArithmetic) now:
/// # Safety
///
/// For a `T: AtomicAdd<Rhs>`, the addition result of a valid bit
/// pattern of `T` and a `T::Repr` convert from `rhs_into_repr()` should
/// be a valid bit pattern of `T`.
pub unsafe trait AtomicAdd<Rhs = Self>: AllowAtomic {
fn rhs_into_repr(rhs: Rhs) -> Self::Repr;
}
Thoughts?
Regards,
Boqun