From owner-svn-src-head@FreeBSD.ORG Mon Oct 6 04:25:55 2014 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 912383B4; Mon, 6 Oct 2014 04:25:55 +0000 (UTC) Received: from mail108.syd.optusnet.com.au (mail108.syd.optusnet.com.au [211.29.132.59]) by mx1.freebsd.org (Postfix) with ESMTP id 4CFF6935; Mon, 6 Oct 2014 04:25:54 +0000 (UTC) Received: from c122-106-147-133.carlnfd1.nsw.optusnet.com.au (c122-106-147-133.carlnfd1.nsw.optusnet.com.au [122.106.147.133]) by mail108.syd.optusnet.com.au (Postfix) with ESMTPS id 4A9421A3A6B; Mon, 6 Oct 2014 15:25:45 +1100 (EST) Date: Mon, 6 Oct 2014 15:25:44 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Mateusz Guzik Subject: Re: svn commit: r272574 - head/sys/sys In-Reply-To: <201410052139.s95LdoJw029807@svn.freebsd.org> Message-ID: <20141006145350.S1175@besplex.bde.org> References: <201410052139.s95LdoJw029807@svn.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=dMCfxopb c=1 sm=1 tr=0 a=7NqvjVvQucbO2RlWB8PEog==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=wSEkhf3f56hUFKgGh-kA:9 a=CjuIK1q_8ugA:10 Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 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: Mon, 06 Oct 2014 04:25:55 -0000 On Sun, 5 Oct 2014, Mateusz Guzik wrote: > Log: > seq_t needs to be visible to userspace > > Pointy hat to: mjg > Reported by: bz > X-MFC: with r272567 The namespace pollution is more disgusting than before. > Modified: head/sys/sys/seq.h > ============================================================================== > --- head/sys/sys/seq.h Sun Oct 5 21:34:56 2014 (r272573) > +++ head/sys/sys/seq.h Sun Oct 5 21:39:50 2014 (r272574) > @@ -29,6 +29,16 @@ > #define _SYS_SEQ_H_ > > #ifdef _KERNEL > +#include > +#endif Namespace pollution. In the kernel, it is the responsibility of .c files to include before any other header except , in case bad headers like this one use inline functions with KASSERT() either now or later. > +#include Namespace pollution. In the kernel, it is the responsibility of .c files to include before any other header, since it has standard namspace pollution that other headers may depend on now or later. This pollution includes , even outside the kernel. It is a documented style bug to include both and . It is a bug to include and not in the kernel, except in very special cases where only headers with a stable API are included after it (otherwise, the others might grow a need for or . Outside of the kernel, the necessary types and no others should be declared in headers. > +/* > + * seq_t may be included in structs visible to userspace > + */ > +typedef uint32_t seq_t; > + > +#ifdef _KERNEL > > /* > * Typical usage: > @@ -54,10 +64,7 @@ > * foo(lobj); > */ > > -typedef uint32_t seq_t; > - > /* A hack to get MPASS macro */ > -#include > #include Now the comment doesn't match the code. The hack is to include both and . MPASS is defined in . has minimal pollution. In particular, it doesn't include . It uses MPASS() with a KASSERT(), but this is in a macro so files that actually use the macro need to include . 's includers are now such files, but polluted instead. This commit moves half of the hack earlier than needed and far from the comment that documents it. > > #include If you remove the part of the hack, some .c files might break. This is a feature. It detects 2 bugs: - nested pollution. IIRC, is now polluted with an include of , so not only files that include are effected - the brokenness of the files that break. is included much more, and any .c file that is missing the include of , or includes it miss-sorted in alphabetical or totally disordered after . Part of the feature is that you get to fix all such broken .c files, or better implement new headers without namespace pollution. The only easy way to avoid pollution from KASSERT() in headers is to only use it in other macros. Some inline functions are so small that this is clean enough. But ones that use KASSERT() are not so small. Just using it makes them too large to inline (when it is enabled). Bruce