* Ingo Molnar <[email protected]> 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
