Messages in this thread | | | Date | Tue, 15 Mar 2016 13:32:53 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH] atomic: Fix bugs in 'fetch_or()' and rename it to 'xchg_or()' |
| |
* Ingo Molnar <mingo@kernel.org> wrote:
> But IMHO this really highlights a fundamental weakness of all this macro magic, > it's all way too fragile. > > Why don't we introduce a boring family of APIs: > > cmpxchg_8() > cmpxchg_16() > cmpxchg_32() > cmpxchg_64() > > xchg_or_32() > xchg_or_64() > ... > > ... with none of this pesky auto-typing property and none of the > macro-inside-a-macro crap? We could do clean types and would write them all in > proper C, not fragile CPP. > > It's not like we migrate between the types all that frequently - and even if we > do, it's trivial. > > hm?
So if we are still on the same page at this point, we'd have to add a pointer variant too I suspect:
cmpxchg_ptr() xchg_ptr()
... whose bitness may differ between architectures(subarches), but it would still be a single variant per architecture, i.e. still with pretty clear type propagation and with a very clear notion of which architecture supports what.
It looks like a lot of work, but it's all low complexity work AFAICS that could be partly automated.
Thanks,
Ingo
| |