From owner-freebsd-smp Fri Apr 20 7: 8:18 2001 Delivered-To: freebsd-smp@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id A501737B43E for ; Fri, 20 Apr 2001 07:08:11 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.3/8.11.3) with ESMTP id f3KE83w16255 for ; Fri, 20 Apr 2001 16:08:06 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200104201408.f3KE83w16255@gratis.grondar.za> To: smp@FreeBSD.ORG Subject: Re: Please review - header cleanups References: In-Reply-To: ; from Bruce Evans "Fri, 20 Apr 2001 07:35:24 +1000." Date: Fri, 20 Apr 2001 16:09:39 +0200 From: Mark Murray Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Said Bruce Evans : > > Ok so this would be a header with only the "struct mtx { ... };" in it, > > and it would be included in all the headers that need to know the size > > and shape of struct mtx (including sys/mutex.h)? > > --- > diff -c2 mutex_types.h~ mutex_types.h [ snippage of patches ] > This removes all the nested includes of except the one in > (the inline functions there should probably not be inline). > It only removes a couple of nested includes of (ones related > to ). Nice! :-) This is an excellent base to work off. Thanks! > LINT compiles after adding includes of (and sometimes > ) to "only" about 50 .c files. Many more probably depend > on the pollution in :-(. About 1/2 of the 50 really should > include . The others mostly use the PROC_* locking macros > in these expand to mtx_lock(), etc. mtx_lock() is another > macro so it can't just be declared. It needs the MPASS() macros from > , so everything that uses the PROC_* macros needs both > and . Eeew. > > > 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. > > > > I think I prefer 1). > > I've put 2 structs in to test things quickly. Strictly, > struct lock_object belongs in a header by itself. So making a seems to be on the cards. > > ONE header to declare _all_/lots_of the "internal" structures? Hmmm... > > See glibc or stddef.h under contrib/gcc. The __need_foo_t stuff selects > the types that will be declared. Ugly, isn't it. Eeew. :-( Now I need a drink... (please don't show be code like that again without warning me!) Seriously - I think I have a pretty good idea now on how to do this. I'll come up with a new patch, and see if I can do something about the PROC_*/mutex entanglement. How bad does a sound? How bad does any <*/*_macros.h> sound (for both macros and inline code) where the header contains approximately _only_ executable stuff as opposed to "pure" declarations? M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message