[PATCH] __FreeBSD_kernel__

Alexander Kabaev kabaev at gmail.com
Tue Jul 5 18:05:35 UTC 2011


On Sun, 3 Jul 2011 17:37:30 +0200
Robert Millan <rmh at debian.org> wrote:

> 2011/7/3 Alexander Kabaev <kabaev at gmail.com>:
> > __linux__ is exactly what __FreeBSD__ is and dies not identify
> > kernel but rather Linux as whole OS, whatever that might be these
> > days.
> >
> > There does not appear to be an universal macro that identifies
> > environment as using Linux kernel regardless of the rest of
> > components used (say, to identify Android and Ubuntu or something
> > embedded with ucLibc as running Linux kernel with different userland
> > implementations).
> 
> I think I'll cowardly try to stick to a practical POV and avoid the
> discussion about names that tends to get people excited about :-)
> 
> So from a purely practical perspective:
> 
> - If __linux__ is defined, this implies you're using a specific
> kernel.
> - If you're using that specific kernel, this implies __linux__ is
> defined.
> 
> which explains why using __linux__ to identify the kernel is useful
> and reliable.
> 
> Can __linux__ be used to identify more things?  Most notably, can
> __linux__ be used to identify userland API?
> 
> - If __linux__ is defined, this does not imply you're using GNU libc.
> - If you're using GNU libc, this does not imply __linux__ is defined.
> 
> which explains why using __linux__ to identify libc is a bad idea.
> However, it can be useful to identify a set of different C libraries
> (Glibc, Bionic, uclibc, etc) if they share the property you're
> interested in.
> 
> -- 
> Robert Millan

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.

-- 
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/c8165aaa/signature.pgp


More information about the freebsd-hackers mailing list