On Thu, Jun 05, 2014 at 06:44:37PM -0400, Pranith Kumar wrote: > Hi Peter, Ingo, > > I see that in the drivers there are the following types of cmpxchg API: > > __cmpxchg64()
That shouldn't really be used, and its only used in intel-iommu.c. > atomic_cmpxchg() > atomic64_cmpxchg() > atomic_long_cmpxchg() They're part of the atomic*_t family and should be used on their respective types, no point in changing that. > local_cmpxchg()(in kernel/events/ring_buffer.c) This is part of the local_t API, also no real point to change that. > this_cpu_cmpxchg() This is part of the this_cpu*() family, and there's no way you can generate the same code using the below to. > cmpxchg() > cmpxchg_local() Which leaves these, which are used in all other cases. > Since cmpxchg() internally handles the width, do you think it makes > sense to replace the above uses of cmpxchg with the document API > (cmpxchg, atomic_cmpxchg, cmpxchg_local)? > > I am willing to do this and wanted to know if it something you think > is worth pursuing. Don't think that's useful. If you really want to go do something, try the annotation I suggested to get the parisc/sparc32 things correct again. Add the __atomic sparse address space and the store()/load() accessors.
pgpKOnA_xqC_J.pgp
Description: PGP signature
