From owner-svn-src-all@FreeBSD.ORG Tue Jul 16 14:35:35 2013 Return-Path: Delivered-To: svn-src-all@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 BC50EB68; Tue, 16 Jul 2013 14:35:35 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id 69378A4B; Tue, 16 Jul 2013 14:35:34 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id 047ADD40A82; Wed, 17 Jul 2013 00:35:22 +1000 (EST) Date: Wed, 17 Jul 2013 00:35:21 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: John Baldwin Subject: Re: svn commit: r253367 - in head/sys: i386/i386 mips/mips powerpc/powerpc sparc64/sparc64 In-Reply-To: <201307161002.15094.jhb@freebsd.org> Message-ID: <20130717001753.C2643@besplex.bde.org> References: <201307151540.r6FFewZc049719@svn.freebsd.org> <201307161002.15094.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=DstvpgP+ c=1 sm=1 tr=0 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 a=PO7r1zJSAAAA:8 a=LB6nCeJpxm0A:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=hDESOa1jty8A:10 a=0fkyT3RvxCmjVirOKNQA:9 a=CjuIK1q_8ugA:10 Cc: svn-src-head@freebsd.org, "Andrey V. Elsukov" , svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 14:35:35 -0000 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. Bruce