From owner-svn-src-projects@FreeBSD.ORG Wed Sep 30 22:38:02 2009 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4230D106566B; Wed, 30 Sep 2009 22:38:02 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id D14E48FC1D; Wed, 30 Sep 2009 22:38:01 +0000 (UTC) Received: from besplex.bde.org (c122-107-125-150.carlnfd1.nsw.optusnet.com.au [122.107.125.150]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n8UMbw0f021329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Oct 2009 08:37:59 +1000 Date: Thu, 1 Oct 2009 08:37:58 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Lawrence Stewart In-Reply-To: <4AC3A7CE.4000207@freebsd.org> Message-ID: <20091001070833.R49077@besplex.bde.org> References: <200909300953.n8U9r3Oo011112@svn.freebsd.org> <20090930203736.D1368@besplex.bde.org> <4AC3A7CE.4000207@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-projects@freebsd.org, src-committers@freebsd.org, Bruce Evans Subject: Re: svn commit: r197638 - projects/tcp_ffcaia2008_8.x/sys/kern X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 22:38:02 -0000 On Wed, 30 Sep 2009, Lawrence Stewart wrote: > Bruce Evans wrote: >> should not be sorted alphabeticaly, since it declares >> things like KASSERT() and (by nested includes) hundreds of inline >> functions (especially ones in , >> and ) which are used in many other headers. It should >> be sorted immediately after where it was. > > Ok got it, thanks for the pointer. Everything compiled fine which is why I > made the change but as you say there must be some "pollution" somewhere. Does > this requirement to keep the systm.h include up top warrant a mention in > style(9) or is it just something to remember? It's not really style, but how the kernel headers are (dis)organized. mumble(9) would be a better place. Probably intro(9), except that doesn't exist. > Random, likely naive thought: is there some way to detect if a header has > been included before or after another header? Could be done fairly easily > with an external script I guess, cpp -M order (used in .depend files) gives the order of include processing. This could be used in the script. I sometimes look at .depend files to find header pollution, but haven't automated this. > but something explicit in the files (some > sort of preprocessor and macro magic?) would be more useful I suspect. > Perhaps there could be a warning emitted if ordering is violated or an > include is detected that shouldn't be there. If done right, it would likely > do the job of educating people about correct ordering/inclusion and go a long > way to reducing "pollution creep". Generally we're trying to reduce prerequisites by including headers in other headers, but this is hard to do without increasing the include mess, and almost everything still has and probably and possibly as prerequisites. I don't know how to detect pollution using only standard C cpp directives. It would be easy using counters as found in primitive macro assemblers, but cpp still doesn't seem to have anything like that. I just looked at cpp.info and found the nonstandard __INCLUDE_LEVEL__ directive which could be used to set a boolean macro when a header is included non-nested. Unfortunately, cpp is also missing the feature of directives within directives (also found in primitive macro assembler) which would be useful here for avoiding having to change every header of interest to set the new macro. Bruce