Date: Wed, 6 Jul 2011 08:49:49 +0200 From: Robert Millan <rmh@debian.org> To: Alexander Kabaev <kabaev@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] __FreeBSD_kernel__ Message-ID: <CAOfDtXNq4N%2BJ1HXRZYWsqdE7kRL%2Bd4NQoaTehfAy4t_3zV5Hyw@mail.gmail.com> In-Reply-To: <20110705160236.1c20d810@kan.dnsalias.net> 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> <20110705160236.1c20d810@kan.dnsalias.net>
next in thread | previous in thread | raw e-mail | index | archive | help
2011/7/5 Alexander Kabaev <kabaev@gmail.com>: > 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__? =C2=A0It is not and b= oth > should be fixed when misused. I think there's an underlying discussion about naming convention here. You said you wanted to leave it out of the list, but it is central to your argument. I try to keep a purely pragmatic approach, but when you say "using this name may work well, but it is wrong", then we have to argue about what is right and what is wrong, and we can't have a pragmatic discussion anymore. It has become http://tinyurl.com/qysbk already. >> 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. It is a timing issue. I don't propose that the macro is used _before_ it has become appropiate to use it. A several year period would be necessary for 3rd party software. --=20 Robert Millan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOfDtXNq4N%2BJ1HXRZYWsqdE7kRL%2Bd4NQoaTehfAy4t_3zV5Hyw>