On Thu, 18 Dec 2025 18:18:17 +0900 Boqun Feng <[email protected]> wrote:
> [Cc parisc, sparc32, arc and hexagon] > > On Thu, Dec 18, 2025 at 06:37:38AM +0900, FUJITA Tomonori wrote: >> This adds atomic xchg helpers with full, acquire, release, and relaxed >> orderings in preparation for i8/i16 atomic xchg support. >> >> The architectures supporting Rust, implement atomic xchg families >> using architecture-specific instructions. So the helpers just call >> them. >> >> Note that the architectures that support Rust handle xchg differently: >> >> - arm64 and riscv support xchg with all the orderings. >> >> - x86_64 and loongarch support only full-ordering xchg. They calls the >> full-ordering xchg for any orderings. >> >> - arm v7 supports only relaxed-odering xchg. It uses __atomic_op_ >> macros to add barriers properly. >> > > Thanks for the work! And please do Cc linux-arch next time when doing > architecture-related changes. We would get more experts to take a look. Will do, thanks. > I think the current implementation expects that xchg() work with normal > store/load, and that requires ARCH_SUPPORTS_ATOMIC_RMW. So could you add > a comment saying the current implementation only support > ARCH_SUPPORTS_ATOMIC_RMW architectures? And when you wire up the rust > helpers, I think using #[cfg(CONFIG_ARCH_SUPPORTS_ATOMIC_RMW)] is a good > idea. This will at least let the !ARCH_SUPPORTS_ATOMIC_RMW archs know > that something is missing here. I will add a comment. ARCH_SUPPORTS_ATOMIC_RMW is required, but we also rely on xchg supporting i8/i16, which is not currently required on the C side, I suppose. As I wrote, at the moment, the architectures that support Rust (x86_64, armv7, arm64, riscv, and loongarch) satisfy these requirements, so my plan was to use cfgs in internal.rs to restrict xchg support to those architectures. _______________________________________________ linux-snps-arc mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-snps-arc
