Date: Mon, 23 Apr 2001 08:04:05 +0200 From: Mark Murray <mark@grondar.za> To: Bruce Evans <bde@zeta.org.au> Cc: smp@FreeBSD.ORG Subject: Re: Kernel include file cleanup take #3. Message-ID: <200104230602.f3N62Tw49163@gratis.grondar.za> In-Reply-To: <Pine.BSF.4.21.0104231421360.3027-100000@besplex.bde.org> ; from Bruce Evans <bde@zeta.org.au> "Mon, 23 Apr 2001 15:07:07 %2B1000." References: <Pine.BSF.4.21.0104231421360.3027-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > http://people.freebsd.org/~markm/patches/sys.SYS_MUTEX.diff.1 > > I'm almost (:-) happy with this version. The includes of <sys/mutex.h> > in <sys/buf.h> and <net/if_var.h> are too hard to move without moving > the inline functions. Right. > <sys/lockmgr.h> was already a subinclude of <sys/lock.h>, and > _SYS_LOCKMGR_H_ is still misspelled (was missing SYS_ and MGR, now > missing SYS_ ...). D'uh. Ok fixed. > You actually made <sys/lockmgr.h> a subinclude of > other headers that need it, and one that doesn't (<sys/conf.h> doesn't > need it directly, but it includes <sys/eventhandler.h> which does). OK. Removed it (plus some other junk) from eventhandler. > <sys/lock.h> doesn't need it any more (but *.c might depend on it > being there). Some of the includes of it are commented on too > verbosely. Empirically, a lot of .c's need it now. (particularly now that I've knocked sys/lockmgr.h out of them). > Some of the new includes seem to be a bit more disordered than necessary. > When inserting in unsorted include lists, I normally insert just before > the first order reversal (not counting param.h or systm.h). Noted. I'll fix that. There may be other ordering issues. This one will take a bit of time. > Please change the copyright owner to yourself. FreeBSD, Inc. still > doesn't exist in a form suitable for holding copyrights. OK. Done. For such small files I'd prefer them to be owned by the project, but I don't care enough to be religious about it. > I'm not sure if the names for the new types headers are right. Perhaps > they should have a leading underscore to inhibit direct inclusion, or > not have the "_types" suffix, to make them less verbose and not hint > that they are limited to types. How about _mutex.h and _lock.h? 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?200104230602.f3N62Tw49163>