[PATCH] Detect GNU/kFreeBSD in user-visible kernel headers
kostikbel at gmail.com
Sat Nov 19 17:56:30 UTC 2011
On Sat, Nov 19, 2011 at 10:32:50AM +0100, Robert Millan wrote:
> 2011/11/18 Robert Millan <rmh at freebsd.org>:
> > 2011/11/17 John Baldwin <jhb at freebsd.org>:
> >> Hmm, I wonder if it's better to use the #ifndef approach rather than #undef
> >> so that when compilers are updated to DTRT we will honor their settings?
> > Well, the compiler is supposed to know better than sys/param.h,
> I gave this a bit more thought....
> The compiler knows about the system it was intended to build for, but
> sys/param.h *is* part of the system we're building for. It's
> impossible for sys/param.h to have the wrong information unless it's
> out of sync with the rest of the headers.
> As for the compiler, on FreeBSD it's hard for the compiler to be out
> of sync, because the system (in comparison with others) is tightly
> packaed and upgrade procedures are well defined.
> But if you take Debian, for example, we use the same compiler to build
> 8-STABLE, 9-STABLE and 10-CURRENT kernels. The compiler has no idea
> which version of FreeBSD the sources it is building come from.
> I wouldn't put compilers in general in a position where they're forced
> to know the FreeBSD major version beforehand because sys/param.h will
> give preference to the information coming from compiler.
> I propose this alternate patch which derives the major number from
> __FreeBSD_version instead.
I fully agree with an idea that compiler is not an authorative source
of the knowledge of the FreeBSD version. Even more, I argue that we shall
not rely on compiler for this at all. Ideally, we should be able to
build FreeBSD using the stock compilers without local modifications.
Thus relying on the symbols defined by compiler, and not the source
is the thing to avoid and consistently remove.
We must do this to be able to use third-party tooldchain for FreeBSD builds.
That said, why not define __FreeBSD_kernel as equal to __FreeBSD_version ?
And then make more strong wording about other systems that use the macro,
e.g. remove 'may' from the kFreeBSD example.
Also, please remove the smile from comment.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20111119/a0d704de/attachment.pgp
More information about the freebsd-current