From mboxrd@z Thu Jan 1 00:00:00 1970 From: Frank Mayhar Subject: Re: [patch 1/2] kernel: introduce brlock Date: Tue, 16 Mar 2010 13:12:28 -0700 Message-ID: <1268770348.1135.17.camel@bobble.smo.corp.google.com> References: <20100316122213.GP2869@laptop> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Nick Piggin , Al Viro , John Stultz , Andi Kleen , linux-fsdevel@vger.kernel.org To: Andreas Dilger Return-path: Received: from smtp-out.google.com ([74.125.121.35]:27566 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756562Ab0CPU0j (ORCPT ); Tue, 16 Mar 2010 16:26:39 -0400 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, 2010-03-16 at 13:01 -0600, Andreas Dilger wrote: > On 2010-03-16, at 06:22, Nick Piggin wrote: > > +#define DEFINE_BRLOCK(name) \ > > + DEFINE_PER_CPU(spinlock_t, name##_lock); \ > > + void name##_lock_init(void) { \ > > + void name##_wlock(void) { \ > > + void name##_wunlock(void) { \ > > + int name##_atomic_dec_and_wlock__failed(atomic_t *a) { > > What makes these macros unpleasant is that it is no longer possible to > tag to the implementation to see what it does, since there is no real > declaration for these locks. > > Is it possible to change the macros to take the lock name as a > parameter, like normal lock/unlock functions do, and then have a > single declaration for br_lock_init(), br_wlock(), etc. macros? This gets my vote as well. (I've been repeatedly annoyed by some of the buffer routines that are constructed this way.) -- Frank Mayhar Google, Inc.