Re: [PATCH 00/20] arch atomic 'cleanup'

[Peter Zijlstra <peterz@infradead.org>]

On Wed, Sep 24, 2014 at 05:54:06PM +0100, Will Deacon wrote:
> Hi Peter,
> 
> On Thu, May 08, 2014 at 02:58:40PM +0100, Peter Zijlstra wrote:
> > This series continues the arch atomic rework started with the smp_mb__
> > interface cleanup.
> > 
> > In this series we (mostly) reduce the atomic implementations by eliminating
> > repetition through use of CPP macros.
> > 
> > A future series will use these macros to implement more atomic ops. With these
> > macros we can end up with more atomic ops while the total LoC still shrinks.
> > 
> > Furthermore, rewrite the asm-generic/atomic implementations to require less and
> > provide more.
> > 
> > This series is compile tested on a number of archs, but only boot tested on
> > x86_64.
> 
> What's the status on this series? I'm currently fleshing out an extension to
> the atomic API that allows more flexible acquire/release semantics and it
> doesn't make sense for me to copy-paste a bunch of code when I could build
> it on top of this instead.

Its in tip/locking/arch and I suppose its headed for the next merge
window.

> Also, do you have any other patches pending in this area? I've lost track...

I do, I have (hopefully) one more series sweeping all archs introducing:
atomic_{or,and,xor,nand}() and then a few patches killing
atomic_{set,clear}_mask(). I just need to find time to write changelogs
and compile test them..

After that I need to go write that gcc-ll/sc proposal so we can pretend
to do generic composite atomic ops in C.

Oh, and like you pointed out, we need to do an audit of the barrier
semantics on some of our atomic functions like add_unless etc.

In other word, plenty to keep entertained.