From owner-freebsd-smp  Sat Apr 21 18:58:40 2001
Delivered-To: freebsd-smp@freebsd.org
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by hub.freebsd.org (Postfix) with ESMTP id B02CA37B424
	for <smp@FreeBSD.ORG>; Sat, 21 Apr 2001 18:58:36 -0700 (PDT)
	(envelope-from bde@zeta.org.au)
Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102])
	by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id LAA22058;
	Sun, 22 Apr 2001 11:58:18 +1000
Date: Sun, 22 Apr 2001 11:57:19 +1000 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-Sender: bde@besplex.bde.org
To: Mark Murray <mark@grondar.za>
Cc: smp@FreeBSD.ORG
Subject: Re: Please review - header cleanups 
In-Reply-To: <200104201408.f3KE83w16255@gratis.grondar.za>
Message-ID: <Pine.BSF.4.21.0104221115520.479-100000@besplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-smp@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

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