Date: Sun, 22 Apr 2001 11:57:19 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Mark Murray <mark@grondar.za> Cc: smp@FreeBSD.ORG Subject: Re: Please review - header cleanups Message-ID: <Pine.BSF.4.21.0104221115520.479-100000@besplex.bde.org> In-Reply-To: <200104201408.f3KE83w16255@gratis.grondar.za>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 20 Apr 2001, Mark Murray wrote: > Said Bruce Evans <bde@zeta.org.au>: > [ snippage of patches ] > > > This removes all the nested includes of <sys/mutex.h> except the one in > > <sys/buf.h> (the inline functions there should probably not be inline). > > It only removes a couple of nested includes of <sys/lock.h> (ones related > > to <sys/mutex.h>). > > Nice! :-) This is an excellent base to work off. Thanks! > > > 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. > > include <sys/mutex.h>. The others mostly use the PROC_* locking macros > > in <sys/proc.h> these expand to mtx_lock(), etc. mtx_lock() is another > > macro so it can't just be declared. It needs the MPASS() macros from > > <sys/lock.h>, so everything that uses the PROC_* macros needs both > > <sys/mutex.h> and <sys/lock.h>. > > Eeew. > > > I've put 2 structs in <sys/mutex_types.h> to test things quickly. Strictly, > > struct lock_object belongs in a header by itself. > > 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. > 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 <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). Bruce 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?Pine.BSF.4.21.0104221115520.479-100000>