On Thu, Aug 29, 2024, at 15:37, Paul E. McKenney wrote:
> My plan is to submit a pull request for the remaining three 8-bit
> cmpxchg() emulation commits into the upcoming merge window. In the
> meantime, I will create similar patches for 16-bit cmpxchg() and perhaps
> also both 8-bit and 16-bit xchg(). I will obviously CC both you and
> Russell on the full set. And if there are hardware-incompatibility
> complaints, we can deal with them, whether by dropping the offending
> pieces of my patches or by whatever other adjustments make sense.
>
> Does that seem like a reasonable approach, or is there a better way?
There is one thing I'd really like to see happen here, and that is
changing the architectures so they only define the fixed-length
__arch_xchg{8,16,32,64} and __arch_cmpxchg{8,16,32,64} helpers,
ideally as inline functions to have type checking on the pointer.
If we make the xchg()/cmpxchg() functiuons handle all sizes
across architectures, that just ends up cementing the type
agnostic macros, so I feel it would be better to have
fixed-size helpers as the generic API so we can phase out the
use of the existing macros on smaller-than-u32 arguments.
The macro is still needed to allow dealing with both integer
and pointer objects, as well as a mix of 'int' and 'long'
arguments on 64-bit, but for normal fixed-size objects I
think we can best use the same method as the current
xchg64()/cmpxchg64().
Arnd
