[PATCH] __FreeBSD_kernel__

[Alexander Kabaev]

On Tue, 5 Jul 2011 21:04:41 +0200
Robert Millan <rmh at debian.org> wrote:

> 2011/7/5 Alexander Kabaev <kabaev at gmail.com>:
> > 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
> 
> Yes, __linux__ is used to identify userland.  And almost 100% of the
> times it is the wrong macro.  We've spent several years fixing this
> kind of bug.  To give just one example among hundreds, here's the
> latest incarnation of __linux__ misuse, reported 3 days ago:
> 
> http://lists.debian.org/debian-bsd/2011/07/msg00013.html
> 
> > just as __FreeBSD__ is.
> 
> Not exactly.  For example, when you see __FreeBSD__, you know what
> libc you're dealing with.
> 

Only because there was no GNU/kFreeBSD before and people got lazy. Using
__FreeBSD__ to identify userland can be considered just as wrong
practice as using __linux__ for the same purpose, yet several years
have been spent fixing this on Linux and quick hack is somehow
appropriate for FreeBSD. Why do you keep arguing that intended use of
__FreeBSD__ is any different than one of __linux__?  It is not and both
should be fixed when misused.

> > You choose to disable
> > __FreeBSD__ in GNU/kFreeBSD presumably because it makes your life
> > porting software easier
> 
> If Debian GNU/kFreeBSD enabled __FreeBSD__, software would expect that
> it is being built on FreeBSD, and make lots of wrong assumptions.
> 
> Debian GNU/kFreeBSD is not FreeBSD.  It is a derivative that builds on
> the kernel of FreeBSD and some of its kernel-specific libraries.  It's
> not surprising that asserting we're FreeBSD via the compiler results
> in breakage (to begin with, even GCC headers wouldn't work properly).
>

Then be a proper OS and have __kFreeBSD__ or what not defined in your
toolchain.

> (similar statements can be made for e.g. Darwin, which I think you're
> familiar with)
> 

Darwin _is_ a proper first-class OS, per above. Last time I checked we
were not forced to change out toolchain in any way to cater to their
uses of components they borrow from FreeBSD.

> > and are asking FreeBSD project to cope with
> > the decision.
> 
> I'm asking FreeBSD project to make life easier for a derivative that
> is, one way or another, part of its ecosystem, at no cost other than
> the time spent discussing the proposal.
> 

Not true, the change does break backward compatibility with older
software if the new macro were to be used as you propose, to enable the
code that is specific to FreeBSD kernel.

> > This breaks compiles of new software with older
> > compilers than do not define the macro,
> 
> As far as I'm concerned, new software isn't supposed to rely on this
> macro unconditionally untill it is deemed reasonable to do so.
> 
> > takes __FreeBSD__ out of
> > symmetry with  __linux__
> 
> I could argue that __FreeBSD_kernel__ would be in symmetry with
> __linux__.  But that's wordplay.  I think we agreed to leave it out of
> the list :-)
> 

See above. Why inventing your own symbol as opposed fixing the use of
existing one is more appropriate on FreeBSD and not on Linux?

> > and other similarly defined platform macros
> > and forces a race to update every other compiler out there to follow
> > the suit.
> 
> There's no race, and nobody forcing it.
> 

Predefined symbols are only useful if all compilers are consistent in
their use.

-- 
Alexander Kabaev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20110705/24d133d3/signature.pgp