From owner-freebsd-current@FreeBSD.ORG Mon Nov 21 09:27:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEDD5106566B; Mon, 21 Nov 2011 09:27:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 2C8AD8FC08; Mon, 21 Nov 2011 09:27:54 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pAL9Roh9010373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Nov 2011 11:27:50 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pAL9RoxD033780; Mon, 21 Nov 2011 11:27:50 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pAL9Robu033779; Mon, 21 Nov 2011 11:27:50 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 21 Nov 2011 11:27:49 +0200 From: Kostik Belousov To: Bruce Evans Message-ID: <20111121092749.GD50300@deviant.kiev.zoral.com.ua> References: <201111170959.56767.jhb@freebsd.org> <201111171632.34979.jhb@freebsd.org> <20111119175620.GV50300@deviant.kiev.zoral.com.ua> <20111120114042.GA1256@thorin> <20111120174807.GY50300@deviant.kiev.zoral.com.ua> <20111121133954.A1108@besplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MsQ2Tn89rTjvu/Ra" Content-Disposition: inline In-Reply-To: <20111121133954.A1108@besplex.bde.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-arch@freebsd.org, Adrian Chadd , freebsd-current@freebsd.org, Robert Millan Subject: Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 09:27:56 -0000 --MsQ2Tn89rTjvu/Ra Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 21, 2011 at 01:45:29PM +1100, Bruce Evans wrote: > On Sun, 20 Nov 2011, Kostik Belousov wrote: >=20 > >On Sun, Nov 20, 2011 at 12:40:42PM +0100, Robert Millan wrote: > >>On Sat, Nov 19, 2011 at 07:56:20PM +0200, Kostik Belousov wrote: > >>>I fully agree with an idea that compiler is not an authorative source > >>>of the knowledge of the FreeBSD version. Even more, I argue that we sh= all > >>>not rely on compiler for this at all. Ideally, we should be able to > >>>build FreeBSD using the stock compilers without local modifications. > >>>Thus relying on the symbols defined by compiler, and not the source > >>>is the thing to avoid and consistently remove. > >>> > >>>We must do this to be able to use third-party tooldchain for FreeBSD= =20 > >>>builds. > >>> > >>>That said, why not define __FreeBSD_kernel as equal to __FreeBSD_versi= on=20 > >>>? > >>>And then make more strong wording about other systems that use the mac= ro, > >>>e.g. remove 'may' from the kFreeBSD example. > >>>Also, please remove the smile from comment. > >> > >>Ok. New patch attached. > > > >And the last, question, why not do > >#ifndef __FreeBSD_kernel__ > >#define __FreeBSD_kernel__ __FreeBSD_version > >#endif > >? > > > >#undef is too big tools tool apply there, IMO. >=20 > #ifndef is too big to apply here, IMO :-). __FreeBSD_kernel__ is in the > implementation namespace, so any previous definition of it is a bug. The > #ifndef breaks the warning for this bug. FreeBSD does not need it at all. There are some implementations that use FreeBSD kernel, and which could potentially benefit from providing its own value for __FreeBSD_kernel. I was only tried to be nice for the out-of-tree implementations, it boils down to kFreeBSD project preferences. >=20 > And why not use FreeBSD style? In KNF, the fields are separated by > tabs, not spaces. In FreeBSD style, trailing underscores are not used > for names in the implementation namespace, since they have no effect > on namespaces. The name __FreeBSD_version is an example of this. Does > existing practice require using the name with the trailing underscores? --MsQ2Tn89rTjvu/Ra Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7KGZUACgkQC3+MBN1Mb4hnkQCeIbVEc2t+iid/4Az+A/ujTt7g ZkIAoOKQNSWGsnqSPDR635aoifSLKuVJ =XKUs -----END PGP SIGNATURE----- --MsQ2Tn89rTjvu/Ra--