Date: Sun, 22 Apr 2001 09:12:25 +0200 From: Mark Murray <mark@grondar.za> Cc: smp@FreeBSD.ORG Subject: Re: Please review - header cleanups Message-ID: <200104220710.f3M7Asw38713@gratis.grondar.za> In-Reply-To: <Pine.BSF.4.21.0104221115520.479-100000@besplex.bde.org> ; from Bruce Evans <bde@zeta.org.au> "Sun, 22 Apr 2001 11:57:19 %2B1000." References: <Pine.BSF.4.21.0104221115520.479-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Said Bruce Evans <bde@zeta.org.au>: > > > LINT compiles after adding includes of <sys/mutex.h> (and sometimes > > > <sys/lock.h>) to "only" about 50 .c files. Many more probably depend > > > on the pollution in <sys/buf.h> :-(. About 1/2 of the 50 really should > > I tried cleaning up <sys/buf.h> and didn't find a good way. There is > also pollution related to curproc in <sys/buf.h>. <sys/buf.h> includes > <sys/proc.h> to get curproc defined so that the inlines in <sys/buf.h> > compile. Compiling these inlines only when they are used and not > including <sys/proc.h> shows that many places have come to depend on > <sys/buf.h> for its side effect of declaring curproc. What a mess. > > So making a <sys/lock_types.h> seems to be on the cards. > > The mess for <sys/lock.h> is much older and messier than for <sys/mutex.h>. > Now, <sys/lock.h> is sort of an extension of <sys/mutex.h>, but most places > that include it are for its (intentional) side effect of including the > old lock interface, <sys/lockmgr.h>. The old lock interface will be going > away, so we shouldn't move the include of <sys/lockmgr.h> to *.c. OTOH, > the entanglement of <sys/lock*.h> makes it difficult to include > <sys/lock.h> in the right places (if any). I think the next step should > be to include <sys/lockmgr.h> instead of <sys/lock.h> in *.h. Damn. :-). I went and put lockmgr into .c's locally. NP - I fix. > > How bad does a <sys/proc_macros.h> 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? > > I don't see how this would help. .c files can't include *_macros.h > without knowing too many implementation details, and .h files can't > include them without getting lots of pollution (since lots of interfaces > are needed to implement complicated inline functions or to call > complicated macros like mtx_lock()) (unless *_macros.h provide > alternative non-polluting interfaces for _everything_ relevant, which > I think would be too much work). Yuk. OK, thanks! 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104220710.f3M7Asw38713>