From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755251AbdC3Gnp (ORCPT ); Thu, 30 Mar 2017 02:43:45 -0400 Received: from mail-wr0-f194.google.com ([209.85.128.194]:35688 "EHLO mail-wr0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751941AbdC3Gno (ORCPT ); Thu, 30 Mar 2017 02:43:44 -0400 Date: Thu, 30 Mar 2017 08:43:39 +0200 From: Ingo Molnar To: Mark Rutland Cc: Dmitry Vyukov , peterz@infradead.org, mingo@redhat.com, akpm@linux-foundation.org, will.deacon@arm.com, aryabinin@virtuozzo.com, kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, x86@kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 4/8] asm-generic: add atomic-instrumented.h Message-ID: <20170330064339.GA20935@gmail.com> References: <20170329171526.GB26135@leverpostej> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170329171526.GB26135@leverpostej> 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 * Mark Rutland wrote: > With some minimal CPP, it can be a lot more manageable: > > ---- > #define INSTR_ATOMIC_XCHG(order) \ > static __always_inline int atomic_xchg##order(atomic_t *v, int i) \ > { \ > kasan_check_write(v, sizeof(*v)); \ > arch_atomic_xchg##order(v, i); \ > } > > #define INSTR_ATOMIC_XCHG() > > #ifdef arch_atomic_xchg_relaxed > INSTR_ATOMIC_XCHG(_relaxed) > #define atomic_xchg_relaxed atomic_xchg_relaxed > #endif > > #ifdef arch_atomic_xchg_acquire > INSTR_ATOMIC_XCHG(_acquire) > #define atomic_xchg_acquire atomic_xchg_acquire > #endif > > #ifdef arch_atomic_xchg_relaxed > INSTR_ATOMIC_XCHG(_relaxed) > #define atomic_xchg_relaxed atomic_xchg_relaxed > #endif Yeah, small detail: the third one wants to be _release, right? > Is there any objection to some light CPP usage as above for adding the > {relaxed,acquire,release} variants? No objection from me to that way of writing it, this still looks very readable, and probably more readable than the verbose variants. It's similar in style to linux/atomic.h which has a good balance of C versus CPP. What I objected to was the deep nested code generation approach in the original patch. CPP is fine in many circumstances, but there's a level of (ab-)use where it becomes counterproductive. Thanks, Ingo