From owner-svn-src-all@FreeBSD.ORG Mon Jun 14 13:26:18 2010 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 385871065673; Mon, 14 Jun 2010 13:26:18 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by mx1.freebsd.org (Postfix) with ESMTP id C419B8FC18; Mon, 14 Jun 2010 13:26:17 +0000 (UTC) Received: from c122-106-175-69.carlnfd1.nsw.optusnet.com.au (c122-106-175-69.carlnfd1.nsw.optusnet.com.au [122.106.175.69]) by mail04.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o5EDQFmf013173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jun 2010 23:26:15 +1000 Date: Mon, 14 Jun 2010 23:26:14 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Lawrence Stewart In-Reply-To: <4C14E012.7080902@freebsd.org> Message-ID: <20100614230205.A37830@delplex.bde.org> References: <201006130239.o5D2du3m086332@svn.freebsd.org> <20100613101025.GD1320@garage.freebsd.pl> <4C14E012.7080902@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Pawel Jakub Dawidek Subject: Re: svn commit: r209119 - head/sys/sys X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 13:26:18 -0000 On Sun, 13 Jun 2010, Lawrence Stewart wrote: > On 06/13/10 20:10, Pawel Jakub Dawidek wrote: >> On Sun, Jun 13, 2010 at 02:39:55AM +0000, Lawrence Stewart wrote: >>> Log: >>> Add a utility macro to simplify calculating an aggregate sum from a >>> DPCPU >>> counter variable. >>> >>> Sponsored by: FreeBSD Foundation >>> Reviewed by: jhb, rpaulo, rwatson (previous version of patch) >>> MFC after: 1 week >>> >>> Modified: >>> head/sys/sys/pcpu.h >>> >>> Modified: head/sys/sys/pcpu.h >>> ============================================================================== >>> --- head/sys/sys/pcpu.h Sun Jun 13 01:27:29 2010 (r209118) >>> +++ head/sys/sys/pcpu.h Sun Jun 13 02:39:55 2010 (r209119) >>> @@ -106,6 +106,17 @@ extern uintptr_t dpcpu_off[]; >>> #define DPCPU_ID_GET(i, n) (*DPCPU_ID_PTR(i, n)) >>> #define DPCPU_ID_SET(i, n, v) (*DPCPU_ID_PTR(i, n) = v) >>> >>> +/* >>> + * Utility macros. >>> + */ >>> +#define DPCPU_SUM(n, var, sum) >>> \ >>> +do { >>> \ >>> + (sum) = 0; \ >>> + u_int i; \ >>> + CPU_FOREACH(i) \ >>> + (sum) += (DPCPU_ID_PTR(i, n))->var; \ >>> +} while (0) >> >> I'd suggest first swapping variable declaration and '(sum) = 0;'. Of course. Also fix the lexical style bugs: - space instead of tab after #define - "do {" at the beginning of a line (see queue.h for normal style) - missing blank line after declarations - missing braces around loop body (*). > > Can do (will wait until consensus on other issues is reached first before > tweaking though). > >> Also using 'i' as a counter in macro can easly lead to name collision. > > I had a similar concern but after chatting with John on IRC felt it wasn't > such a big deal in this case. > >> If you need to do it, I'd suggest '_i' or something. > > Could do... is it worth it? > >> Maybe it would be better to make it an inline function rather than macro? > > Inlining it could be annoying with respect to the types used in the function > prototype, no? I suspect it would be more useful keeping it as a macro if > possible. Inlining it is impossible for the same reason that parenthesizing all the macro args would be impossible -- `var' is a name and parenthesizing its use would give the syntax error foo->(var). Not sure about (n). It's a little surprising that parenthesizing works for lvalues like (sum) (it works because lvalues include certain expressions including parenthesized ones, but I wonder if it ever makes a difference). BTW, one reason I liked BSD code more than gnu code is that it didn't use so many macros. Macros should only exist when they are not just syntactic sugar, like DPCPU_SUM() and unlike CPU_FOREACH(). (*) style(9) recommends leaving out these unnecessary braces. However, mistakes like CPU_FOREACH() look less like syntax errors with the braces than without them; the braces at least confuse indent(1) into not making a mess. indent(1) already knows that it doesn't understand macros so it doesn't reformat them, so this doesn't quite apply here. Bruce