From owner-freebsd-current@FreeBSD.ORG Tue Nov 22 13:30:07 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 296CF1065670; Tue, 22 Nov 2011 13:30:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E995D8FC1C; Tue, 22 Nov 2011 13:30:06 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 9C5EF46B23; Tue, 22 Nov 2011 08:30:06 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 17571B947; Tue, 22 Nov 2011 08:30:06 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Date: Tue, 22 Nov 2011 08:24:07 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <20111121092749.GD50300@deviant.kiev.zoral.com.ua> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201111220824.07823.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 22 Nov 2011 08:30:06 -0500 (EST) Cc: Kostik Belousov , Robert Millan , freebsd-current@freebsd.org, Adrian Chadd 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: Tue, 22 Nov 2011 13:30:07 -0000 On Monday, November 21, 2011 12:39:26 pm Robert Millan wrote: > (replying with Debian hat this time) > > 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. > > 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. > > 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. > > 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. > > 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. > > 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. Is __FreeBSD_version defined if __FreeBSD_kernel__ is defined on kFreeBSD? Most things that want to check versions that I've seen do something like this: #ifdef __FreeBSD__ #include #if __FreeBSD_version > XXXXXXX /* use new feature */ #endif #endif If __FreeBSD_version is defined when __FreeBSD_kernel__ is defined, then I think having it be empty would be ok as it would allow usage as above. Also, in that case I think __FreeBSD_kernel__ is much closer in meaning to __FreeBSD__ than to __FreeBSD_version. -- John Baldwin