Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 Jun 2010 13:50:10 +0000
From:      mdf@FreeBSD.org
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        svn-src-head@freebsd.org, Lawrence Stewart <lstewart@freebsd.org>, svn-src-all@freebsd.org, src-committers@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org>
Subject:   Re: svn commit: r209119 - head/sys/sys
Message-ID:  <AANLkTikR9LhvtjfzLpgVr7oV9uzp2n4dVWY-030UA4Hp@mail.gmail.com>
In-Reply-To: <20100614230205.A37830@delplex.bde.org>
References:  <201006130239.o5D2du3m086332@svn.freebsd.org> <20100613101025.GD1320@garage.freebsd.pl> <4C14E012.7080902@freebsd.org> <20100614230205.A37830@delplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
> BTW, one reason I liked BSD code more than gnu code is that it didn't
> use so many macros. =A0Macros should only exist when they are not just
> syntactic sugar, like DPCPU_SUM() and unlike CPU_FOREACH().

As a style question, I do understand (generally) why too many macros
make the code confusing.  However, the *FOREACH macros all fit the
same pattern and having a macro to iterate protects one against
changes in the implementation -- there's a single location to change
if e.g. we want to make CPU_FOREACH use a bitwise operator to
determine the next non-zero bit, rather than testing each
individually.

So what I'm asking is, how do we balance the simplicity of the code
(no "unnecessary" macros) versus the simplicity of making certain
kinds of infrastructure changes simpler?

Thanks,
matthew



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTikR9LhvtjfzLpgVr7oV9uzp2n4dVWY-030UA4Hp>