Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers

(replying with Debian hat this time)

2011/11/21 Kostik Belousov <kostikbel_at_gmail.com>:
> 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.

-- 
Robert Millan