Date: Fri, 11 Apr 1997 09:29:35 +1000 (EST) From: Darren Reed <avalon@coombs.anu.edu.au> To: terry@lambert.org (Terry Lambert) Cc: hackers@freebsd.org Subject: Re: detecting kernel version at compile time Message-ID: <199704102335.QAA09067@freefall.freebsd.org> In-Reply-To: <199704102256.PAA10047@phaeton.artisoft.com> from "Terry Lambert" at Apr 10, 97 03:56:07 pm
next in thread | previous in thread | raw e-mail | index | archive | help
In some mail from Terry Lambert, sie said: > > Then you are lucky that this is an informational change, and not one > that implies an interface change, and therefore work for third party > developers... Lets see...firstly, there is <osreldate.h> which is particular to FreeBSD. Including that file always requires #ifdef's for FreeBSD. Now you want to introduce <sys/osreldate.h>. That is going to be conditional on what is in <osreldate.h>. THen code which currently checks for __FreeBSD_version must be adapted to see if __FreeBSD_sysversion exists. Why weren't __FreeBSD_version & __FreeBSD_sysversion (IF you need both) put in <sys/param.h> ? For starters, one doesn't need to worry about extra include files, although removing <osreldate.h> would not be good, now. Whilst it may not be an interface change, it is a change which tells us about which interface is present. Further still, there is the uselessness of __FreeBSD__ in some circumstances. Although it may be defined and have a numeric value, it can have a value totally unrelated to which version of the OS it is. To my mind, mixing kernel versions with different "userland" versions is a mistake. At this point in time, FreeBSD is a single combined product, both kernel and userland, distinct from other OS's such as Linux which have a very separate Kernel & userland components. From this, I'd argue that __FreeBSD_version is sufficient and that encouragement for kernel & userland "skew" isn't wise (unless libkvm and other things in the kernel access by user programs NEVER change). [...] > Though it would be smart if third party developers specified a version > stamp (generally for a release) under which their stuff is *expected* to > work. Unfortunately, you can't do that in the face of CVSup (unless > this change is adopted and you check the value -- you don't *have* to > check the value -- you can load anyway and crash newer kernels instead, > if you want, like the star_saver_mod...). Well, let me give you some more of my thoughts. Once I have IP Filter working on a particular version of FreeBSD, there are usually no more problems with that rev. However, for the next n months, I get people asking "when will it work on -CURRENT ?" or "when will it work on X.Y-STABLE ?", etc. Personally, I refuse to even atempt to support anything that isn't marked as a "release" (and available on CD-ROm if I can :).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704102335.QAA09067>