svn commit: r253367 - in head/sys: i386/i386 mips/mips powerpc/powerpc sparc64/sparc64

[John Baldwin]

On Tuesday, July 16, 2013 10:35:21 am Bruce Evans wrote:
> On Tue, 16 Jul 2013, John Baldwin wrote:
> 
> > On Monday, July 15, 2013 11:40:58 am Andrey V. Elsukov wrote:
> >> Log:
> >>   Include sys/systm.h after sys/param.h.
> >>
> >>   Suggested by:	pluknet
> >
> > Does this fix something?
> 
> Style bugs at least.  sys/systm.h defines APIs which may be used in
> other headers (in inline functions, typically for KASSERT(); otherwise
> the order is not so important).  Sometimes no other header included
> by the file has such uses at the time that the include of sys/systm.h
> is sorted.  Then a sorting error is just a style bug.  It may become
> a bug later when one of the other included headers grows a dependency
> on sys/systm.h.
> 
> > The normal style rule IIUC is to put <sys/types.h> or <sys/param.h> first,
> > and then to sort alphabetically.
> 
> The normal style rule doesn't apply to sys/systm.h.  It is almost as much
> a prerequisite for everything in the kernel as sys/param.h.
> 
> Explicitly including sys/types.h at all in kernel files is normally at
> least a style bug.  If sys/systm.h is included too, then it is just a
> style bug to include both explicitly.  Otherwise, sys/types.h only works
> if no other header included by the file has any dependencies on sys/systm.h
> (or if one of the other headers satisifies such dependencies for itself and
> for later includes by a polluting nested include of sys/systm.h).  Now
> almost any use of an API in sys/systm.h gives a dependency (for example,
> use of KASSERT() in another macro and not in an inline function gives a
> dependency).  As for misordered includes of sys/systm.h, this may change
> from a style bug to a bug later if one of the other included headers grows
> a dependency on sys/systm.h.  Now it may also change from a style bug to a
> bug later in more cases when pollution is removed from one of the other
> headers.
> 
> sys/systm.h should probably be standard pollution in sys/param.h.  Then
> explicitly including it at all would be a style bug, lile explicitly
> including one of the other headers that are standard pollution in
> sys/param.h.

I would be fine by codifying this via a nested include in <sys/param.h> in
the _KERNEL case of <sys/systm.h> if you think that is the best fix.

-- 
John Baldwin