From owner-svn-src-head@FreeBSD.ORG Tue Jul 16 14:58:43 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 87B4A7E0; Tue, 16 Jul 2013 14:58:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 62082BEA; Tue, 16 Jul 2013 14:58:43 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id ADD26B94F; Tue, 16 Jul 2013 10:58:42 -0400 (EDT) From: John Baldwin To: Bruce Evans Subject: Re: svn commit: r253367 - in head/sys: i386/i386 mips/mips powerpc/powerpc sparc64/sparc64 Date: Tue, 16 Jul 2013 10:40:59 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201307151540.r6FFewZc049719@svn.freebsd.org> <201307161002.15094.jhb@freebsd.org> <20130717001753.C2643@besplex.bde.org> In-Reply-To: <20130717001753.C2643@besplex.bde.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201307161040.59919.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 16 Jul 2013 10:58:42 -0400 (EDT) Cc: svn-src-head@freebsd.org, "Andrey V. Elsukov" , svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 14:58:43 -0000 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 or 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 in the _KERNEL case of if you think that is the best fix. -- John Baldwin