From owner-freebsd-smp  Sun Apr 22  0:11: 7 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 EC0CD37B423
	for <smp@FreeBSD.ORG>; Sun, 22 Apr 2001 00:11:00 -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 f3M7Asw38713
	for <smp@FreeBSD.ORG>; Sun, 22 Apr 2001 09:10:56 +0200 (SAST)
	(envelope-from mark@grondar.za)
Message-Id: <200104220710.f3M7Asw38713@gratis.grondar.za>
Cc: smp@FreeBSD.ORG
Subject: Re: Please review - header cleanups 
References: <Pine.BSF.4.21.0104221115520.479-100000@besplex.bde.org> 
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 +1000."
Date: Sun, 22 Apr 2001 09:12:25 +0200
From: Mark Murray <mark@grondar.za>
Sender: owner-freebsd-smp@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

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