From owner-svn-src-all@FreeBSD.ORG Mon Jun 14 15:42:14 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 E1C36106564A; Mon, 14 Jun 2010 15:42:14 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by mx1.freebsd.org (Postfix) with ESMTP id 42E7F8FC16; Mon, 14 Jun 2010 15:42:14 +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 mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o5EFgBBc026528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jun 2010 01:42:12 +1000 Date: Tue, 15 Jun 2010 01:42:10 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: John Baldwin In-Reply-To: <201006141002.59464.jhb@freebsd.org> Message-ID: <20100615011554.F37940@delplex.bde.org> References: <201006130239.o5D2du3m086332@svn.freebsd.org> <20100614230205.A37830@delplex.bde.org> <201006141002.59464.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: mdf@freebsd.org, src-committers@freebsd.org, Pawel Jakub Dawidek , svn-src-all@freebsd.org, Bruce Evans , svn-src-head@freebsd.org, Lawrence Stewart 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 15:42:15 -0000 On Mon, 14 Jun 2010, John Baldwin wrote: > On Monday 14 June 2010 9:50:10 am mdf@freebsd.org wrote: [bde wrote] >>> 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(). >> >> 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. I usually prefer readability to making the implementation easier to change. Readability includes seeing all the details so that you can understand and debug them. Functions may also hide the details in an effectively similar way for reading (browsing) but not from debugging. > In the case of CPU_FOREACH() there is a very good chance that the > implementation details will change when we switch from cpumask_t to cpuset_t, > which is part of the reason I added it. I am less of a fan of macros that > just wrap TAILQ_FOREACH() (note that there isn't a PCPU_FOREACH() since you > can already do this via SLIST_FOREACH() now for example) such as > FOREACH_PROC_IN_SYSTEM(). I view the queue constructor and access macros as a necessary evil because they can't be written as inline functions (except in C++?). This doesn't apply to the iterator macros. > CPU_FOREACH() has additional logic in that it hides > the CPU_ABSENT() stuff, so to me it doesn't quite fall in that class. (Some > code was using pcpu_find() instead of CPU_ABSENT() to determine absent CPUs as > well FWIW.) Maybe it is the magic in them that I dislike most. I have yet to see a debugger that can even automatically print the literal macro definition when displaying lines near a macro, let alone prettyprint the context-dependent macro expansion and allow stepping through or over the expansion. gdb has problems in this area even with inline functions. Bruce