On Thu, Aug 29, 2024 at 09:56:52PM +0200, Arnd Bergmann wrote:
> 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().
So the idea is to have architecture-independent xchg()/cmpxchg() that
invoke the __arch_xchg{8,16,32,64} and __arch_cmpxchg{8,16,32,64} helpers?
Seems plausible to me.
How can I best help? My guess is that I should prototype an emulated
xchg() function, given my limited familiarity with the architectures.
Thanx, Paul
