From owner-freebsd-smp Wed Apr 18 16:38:30 2001 Delivered-To: freebsd-smp@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 2C65637B422; Wed, 18 Apr 2001 16:38:27 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id JAA18324; Thu, 19 Apr 2001 09:38:22 +1000 Date: Thu, 19 Apr 2001 09:37:18 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: John Baldwin Cc: Mark Murray , smp@FreeBSD.org Subject: Re: Please review - header cleanups In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 18 Apr 2001, John Baldwin wrote: > On 18-Apr-01 Mark Murray wrote: > > My change is, I believe, in agreement with the first paragraph > > of http://people.freebsd.org/~jasone/smp/ "Project Goal" in that > > it achieves _something_ in the quest of de-threading the chain of > >#includes. Not the whole story, perhaps, but a step in that direction. > > Well, I put that up there because I was under the impression that nested > includes were to be avoided at all costs based on previous discussions with > Bruce. It seems now that Bruce was more just trying to discourage the practice > but not condemning those particular cases as the alternatives were worse. > In the case of determing if headers should use nested #includes, etc. I defer > to Bruce as he is more authoritative in this area. It's nested includes of primary headers (ones that declare standard kernel or application interfaces) that should be avoided. Nested includes of secondary headers (ones that declare only common implementation details, e.g., and , or a carefully selected (small) set of primary interfaces, e.g., ) are OK. Including secondary headers, especially lots of little ones, still gives lots of includes, but shouldn't give nearly as many symbols if the secondary headers are properly implemented, since the secondary headers need not depend on as many other headers. Possible implementations: 1) Do the same things as are planned for `struct timespec': use a tiny header that declares just `struct mtx' and include this header as necessary. 2) Do the same things as are done for size_t: define a macro that declares `struct mtx' in a not so tiny secondary header; include this header and expand it as necessary. This is uglier than (1), but doesn't require so many headers. 3) Combination/variation of on (1)-(2): conditionally declare various structs and types in a not so tiny secondary header; include this header with only the required declarations selected. This method is used in glibc. This is not as ugly as (2), but I think it is slower than both (1) and (2). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message