From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751436AbcFXQex (ORCPT ); Fri, 24 Jun 2016 12:34:53 -0400 Received: from mx2.suse.de ([195.135.220.15]:37798 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750972AbcFXQew (ORCPT ); Fri, 24 Jun 2016 12:34:52 -0400 Date: Fri, 24 Jun 2016 09:34:30 -0700 From: Davidlohr Bueso To: Peter Zijlstra Cc: mingo@kernel.org, davem@davemloft.net, cw00.choi@samsung.com, dougthompson@xmission.com, bp@alien8.de, mchehab@osg.samsung.com, gregkh@linuxfoundation.org, pfg@sgi.com, jikos@kernel.org, hans.verkuil@cisco.com, awalls@md.metrocast.net, dledford@redhat.com, sean.hefty@intel.com, kys@microsoft.com, heiko.carstens@de.ibm.com, James.Bottomley@HansenPartnership.com, sumit.semwal@linaro.org, schwidefsky@de.ibm.com, linux-kernel@vger.kernel.org, Davidlohr Bueso Subject: Re: [PATCH v2 01/12] locking/atomic: Introduce inc/dec calls for FETCH-OP flavors Message-ID: <20160624163430.GA11823@linux-80c1.suse> References: <1466453164-13185-1-git-send-email-dave@stgolabs.net> <1466453164-13185-2-git-send-email-dave@stgolabs.net> <20160621133310.GA24567@linux-80c1.suse> <20160621163611.GA3790@linux-80c1.suse> <20160623090942.GI30154@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20160623090942.GI30154@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 23 Jun 2016, Peter Zijlstra wrote: >Would something like so make sense? > >--- >--- a/include/linux/atomic.h >+++ b/include/linux/atomic.h >@@ -188,15 +188,18 @@ > #endif > #endif /* atomic_fetch_add_relaxed */ > >-#ifndef atomic_fetch_inc >-#define atomic_fetch_inc(v) (atomic_fetch_add(1, v)) >-#endif Hmm perhaps I'm a bit lost in all this CPP maze, but where do you in fact define atomic_fetch_inc() generically here? gcc cannot see it either. Another option could be to add the above for atomic_fetch_inc inside the ifndef atomic_fetch_release. Ie: >- > /* atomic_fetch_inc_relaxed */ > #ifndef atomic_fetch_inc_relaxed >+ >+#ifndef atomic_fetch_inc #define atomic_fetch_inc(v) (atomic_fetch_add(1, v)) >+#define atomic_fetch_inc_relaxed(v) atomic_fetch_add_relaxed(1, (v)) >+#define atomic_fetch_inc_acquire(v) atomic_fetch_add_acquire(1, (v)) >+#define atomic_fetch_inc_release(v) atomic_fetch_add_release(1, (v)) I was under the impression that if the archs don't define their own calls, then we always default to fully ordered. Which is why I based all this ifdefery on what is currently done with the other atomic_fetch_$ops. >+#else /* atomic_fetch_inc */ > #define atomic_fetch_inc_relaxed atomic_fetch_inc > #define atomic_fetch_inc_acquire atomic_fetch_inc > #define atomic_fetch_inc_release atomic_fetch_inc >+#endif /* atomic_fetch_inc */ > > #else /* atomic_fetch_inc_relaxed */ Thanks, Davidlohr