Date: Wed, 18 Apr 2001 13:22:19 +0200 From: Mark Murray <mark@grondar.za> To: Bruce Evans <bde@zeta.org.au> Cc: John Baldwin <jhb@FreeBSD.ORG>, smp@FreeBSD.ORG Subject: Re: Please review - header cleanups Message-ID: <200104181120.f3IBKkw89864@gratis.grondar.za> In-Reply-To: <Pine.BSF.4.21.0104172026390.8215-100000@besplex.bde.org> ; from Bruce Evans <bde@zeta.org.au> "Tue, 17 Apr 2001 21:23:09 %2B1000." References: <Pine.BSF.4.21.0104172026390.8215-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Said Bruce Evans <bde@zeta.org.au>: > > > The SMPng project has a TODO list at > > > http://people.freebsd.org/~jasone/smp/ > > > And I grabbed what I thought would be an easy job one of > > > moving sys/mutex.h out of other "system" headers. > > This is not an easy job. It involves redesigning as many system > structs as possible (without significant loss of space or time > efficiency) to use `struct mtx *' instead of `struct mtx' so that > not so many headers depend on <sys/mutex.h> and/or moving the > declaration of `struct mtx' to its own header and including this > header instead of the full <sys/mutex.h> in system headers. This is, as you say difficult. I took a look at the "struct mutex p_mtx" in struct proc. Its use looks scary :-(. 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. > > It will need a buildworld test as well. > > Parts of userland certainly depends on <sys/mutex.h>. The main > pollution is `struct mtx' in struct proc, struct ucred and in structs > in <net/if_var.h>. Everything that includes <sys/user.h> will fail > the buildworld test. Yeah. Not nearly as much in userland as the kernel, thank ${DEITY}. :-) > > > NOTES: > > > A Helluva lot of files are affected (818, to be precise). The > > > huge majority of them are .c files. Less that 20 are .h's. > > Moving the includes to files that don't depend on <sys/mutex.h> > directly just gives a larger mess. Removing unneeded #includes at a later date is a job that lends itself to automation (see some scripts by PHK in src/tools/). I'd certainly like to do this once the #includes have been untangled. > Note that in all other cases except for networking headers and vm > headers, we have chosen spamming system headers with with includes > that they need directly over spamming .c files with includes that they > need only indirectly (due to headers not being self-sufficient). For > network headers, this is for ancient historical reasons. For vm > headers, it is because David Greenman was annoyed enough at the spam > in the headers to move it to .c files. This is not the correct fix, > but it affects more like 18 files than 818 (since fundamental system > headers like <sys/proc.h> and <sys/vnode.h> don't depend on any vm > headers. Undoing the tangled mess is a big problem. We need a transitional state to achieve it - I believe the spam is it. 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?200104181120.f3IBKkw89864>