From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 10 05:08:08 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 751D6106566C; Sun, 10 Jul 2011 05:08:08 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 2679C8FC13; Sun, 10 Jul 2011 05:08:08 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p6A56T6C012132 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 9 Jul 2011 23:06:29 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20110705201214.GA31647@sandvine.com> Date: Sat, 9 Jul 2011 23:06:28 -0600 Content-Transfer-Encoding: 7bit Message-Id: <005E93BB-0DD4-495A-80E1-E6263C04EB17@bsdimp.com> References: <20110702193724.5c55a6c9@kan.dnsalias.net> <20110703020827.GA5763@sandvine.com> <20110703103531.4a553271@kan.dnsalias.net> <20110705140527.17362ed5@kan.dnsalias.net> <20110705201214.GA31647@sandvine.com> To: Ed Maste X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sat, 09 Jul 2011 23:06:30 -0600 (MDT) Cc: freebsd-hackers@FreeBSD.org, Robert Millan Subject: Re: [PATCH] __FreeBSD_kernel__ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 05:08:08 -0000 I know this is a little late, but... On Jul 5, 2011, at 2:12 PM, Ed Maste wrote: > On Tue, Jul 05, 2011 at 02:05:27PM -0400, Alexander Kabaev wrote: > >> I agree with all of the above reasons, but none of them change the fact >> that __linux__ is used left and right to identify both kernel and >> userland environments just as __FreeBSD__ is. You choose to disable >> __FreeBSD__ in GNU/kFreeBSD presumably because it makes your life >> porting software easier and are asking FreeBSD project to cope with >> the decision. This breaks compiles of new software with older >> compilers than do not define the macro, takes __FreeBSD__ out of >> symmetry with __linux__ and other similarly defined platform macros >> and forces a race to update every other compiler out there to follow >> the suit. I fail to see the benefits out-weighting the drawbacks in >> this scenario. > > There are two separate issues here - the macro itself, and where it's > defined. > > On the topic of the macro itself, __FreeBSD__ implies something about > the kernel and the libc, and it used to be the same case for __linux__. > This became broken for __linux__ once people started combining a Linux > kernel with other than glibc, and it would break if those combining > the FreeBSD kernel with another libc defined __FreeBSD__. > > (A note on terminology - some may dislike the "GNU/" name for various > reasons, but either way their project is properly called "Debian > GNU/kFreeBSD." I'll refer to it as "kFreeBSD" here for brevity though, > since the kFreeBSD part is the unique aspect of this project vs other > Debian ports, and the full name is rather awkward to type.) > > kFreeBSD can't define __FreeBSD__, since it will break any existing > software that uses that to infer something about the libc in use. So, > that project had a choice; they could have created a new macro > __Debian_GNU_kFreeBSD__, say, that indicates the kernel and libc in use. > However, defining __FreeBSD_kernel__ (and __glibc__ presumably) makes > more sense, and actually reduces the porting effort for both them and > the FreeBSD porters. Any effort on porting software to the FreeBSD > kernel done by either project is then applicable to the other. If > kFreeBSD project members make a change to get some piece of software > working on a FreeBSD kernel and then gets that change commited upstream > we can take advantage of that work without any additional effort on our > part. I think we should define this. > On the topic of where such a macro should be defined I originally had > no strong opinion. However, valid points have been raised about > compiling software for FreeBSD using compilers that are not the one in > the base system (from ports or otherwise, and GCC or otherwise). This > I think is a very valid point and one that would make me lean towards > defining the macro in sys/param.h. How workable is it to #include > sys/param.h to pick up the macro where needed? Why can't the other compilers conform to the new standard instead? Warner