Date: Tue, 5 Jul 2011 16:02:36 -0400 From: Alexander Kabaev <kabaev@gmail.com> To: Robert Millan <rmh@debian.org> Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] __FreeBSD_kernel__ Message-ID: <20110705160236.1c20d810@kan.dnsalias.net> In-Reply-To: <CAOfDtXOQjhm44RcOJPvrR-c%2BKnU1RcPn%2BajOw_EjUoWy%2B77Jdg@mail.gmail.com> References: <CAOfDtXPUxQO1zbnxh8sh%2By7g=d8QaH2svYtEQJ06L4d%2BQKG8VA@mail.gmail.com> <20110702193724.5c55a6c9@kan.dnsalias.net> <20110703020827.GA5763@sandvine.com> <CAGH67wQAv4Tf8HjccN2GZzgD2u1ZrORABtGehxXjeg109%2BRNWQ@mail.gmail.com> <20110703103531.4a553271@kan.dnsalias.net> <CAOfDtXOcfbNw6St5CMN4GB_psf8hZEV=hpL4q3mmQXqWeLmqXQ@mail.gmail.com> <20110705140527.17362ed5@kan.dnsalias.net> <CAOfDtXOQjhm44RcOJPvrR-c%2BKnU1RcPn%2BajOw_EjUoWy%2B77Jdg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/t0UylTkCbab3vSAd11tfxmX Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On Tue, 5 Jul 2011 21:04:41 +0200 Robert Millan <rmh@debian.org> wrote: > 2011/7/5 Alexander Kabaev <kabaev@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 >=20 > 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: >=20 > http://lists.debian.org/debian-bsd/2011/07/msg00013.html >=20 > > just as __FreeBSD__ is. >=20 > Not exactly. For example, when you see __FreeBSD__, you know what > libc you're dealing with. >=20 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 >=20 > If Debian GNU/kFreeBSD enabled __FreeBSD__, software would expect that > it is being built on FreeBSD, and make lots of wrong assumptions. >=20 > 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) >=20 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. >=20 > 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. >=20 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, >=20 > 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. >=20 > > takes __FreeBSD__ out of > > symmetry with =9A__linux__ >=20 > 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 :-) >=20 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. >=20 > There's no race, and nobody forcing it. >=20 Predefined symbols are only useful if all compilers are consistent in their use. --=20 Alexander Kabaev --Sig_/t0UylTkCbab3vSAd11tfxmX Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iD8DBQFOE23gQ6z1jMm+XZYRAp35AKDSce56QsmXhqjZJDSu5B1oRq/RrQCeOL2L qIkPZw+W82oWQ3B4a8/ik/o= =KSgC -----END PGP SIGNATURE----- --Sig_/t0UylTkCbab3vSAd11tfxmX--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110705160236.1c20d810>