lkml.org 
[lkml]   [2016]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2016-03-15 14:21    [W:0.155 / U:0.596 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site