[PATCH] __FreeBSD_kernel__

[Ed Maste]

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.

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?

-Ed Maste