From owner-freebsd-smp Wed Apr 18 4:21:14 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 9446237B422; Wed, 18 Apr 2001 04:21:06 -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 f3IBKkw89864; Wed, 18 Apr 2001 13:20:50 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200104181120.f3IBKkw89864@gratis.grondar.za> To: Bruce Evans Cc: John Baldwin , smp@FreeBSD.ORG Subject: Re: Please review - header cleanups References: In-Reply-To: ; from Bruce Evans "Tue, 17 Apr 2001 21:23:09 +1000." Date: Wed, 18 Apr 2001 13:22:19 +0200 From: Mark Murray Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Said Bruce Evans : > > > 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 and/or moving the > declaration of `struct mtx' to its own header and including this > header instead of the full 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 . The main > pollution is `struct mtx' in struct proc, struct ucred and in structs > in . Everything that includes 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 > 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 and 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