From owner-freebsd-arch@FreeBSD.ORG Tue Nov 22 09:35:24 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9253E1065670; Tue, 22 Nov 2011 09:35:24 +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 2785F8FC15; Tue, 22 Nov 2011 09:35:23 +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 pAM9ZGxc009372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Nov 2011 11:35:16 +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 pAM9ZG9E038036; Tue, 22 Nov 2011 11:35:16 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pAM9ZF43038035; Tue, 22 Nov 2011 11:35:15 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 22 Nov 2011 11:35:15 +0200 From: Kostik Belousov To: Robert Millan Message-ID: <20111122093515.GK50300@deviant.kiev.zoral.com.ua> References: <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> <20111121092749.GD50300@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="313G32quqWeq5lpS" Content-Disposition: inline In-Reply-To: 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: Adrian Chadd , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 09:35:24 -0000 --313G32quqWeq5lpS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 21, 2011 at 06:39:26PM +0100, Robert Millan wrote: > (replying with Debian hat this time) >=20 > 2011/11/21 Kostik Belousov : > > There are some implementations that > > use FreeBSD kernel, and which could potentially benefit from providing > > its own value for __FreeBSD_kernel. >=20 > Actually, we wouldn't be able to provide a different value for the > macro (whatever its name). Our compiler simply doesn't know which > version of the kernel it is building for. Only the headers do, but if > we define it in the headers we'd just use the FreeBSD definitions. >=20 > Our compiler defines __FreeBSD_kernel__ as an empty macro, I don't > expect this will change because unlike with FreeBSD, on Debian there > are strong technical limitations to making it a number. >=20 > If __FreeBSD_kernel__ is to be defined in FreeBSD land, may I suggest > that it is defined as an empty macro as well? This covers the vast > majority of cases (e.g. like the ones in my initial patch which > started this discussion), and it doesn't preclude the possibility that > this macro becomes a number without breaking backward compatibility. >=20 > OTOH once you define it as a number, it becomes relevant whether you > did it with #ifndef or with #undef, and so you have to commit to it. >=20 > Just to make it clear: It's no problem to me if it's defined as a > number, but it doesn't help much either. At least from Debian POV it's > not worth making a big argument about. It could be a good idea from > FreeBSD POV, but please only do this if it's useful to FreeBSD. >=20 I am fine with __FreeBSD_kernel being empty, please submit the patch. --313G32quqWeq5lpS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7LbNMACgkQC3+MBN1Mb4gXaQCfdYpkCc+hivE5dTAUIUj7IvKa 7owAn1Myrkr9h2XERuYtrgXTEMgMATlb =uxi0 -----END PGP SIGNATURE----- --313G32quqWeq5lpS--