Date: Thu, 10 Apr 1997 17:18:14 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: avalon@coombs.anu.edu.au (Darren Reed) Cc: terry@lambert.org, hackers@freebsd.org Subject: Re: detecting kernel version at compile time Message-ID: <199704110018.RAA10243@phaeton.artisoft.com> In-Reply-To: <199704102335.QAA13275@coyote.Artisoft.COM> from "Darren Reed" at Apr 11, 97 09:29:35 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. 1) <sys/xxx.h> files can *never* depend on <xxx.h> files. 2) You only have to check the version if you want to protect against a crash better than you currently do. > 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. I don't know; I've never used <osreldate.h>. It really only applies to the installation insteance of the toolset, and the instances of the API enacted by the standard (not system) include files, IMO. It seems to me that it's a concession to vendors who don't want to check the BSD manifest constants across BSD platforms. > Whilst it may not be an interface change, it is a change which tells us > about which interface is present. The kernel "interfaces" (the structures documented in /usr/include/sys/*.h and accessed via libkvm can't really be counted as interfaces -- vendors should not access them unless they are supplying system software) were totally *undocumented* in changes involving the kernel but not the build system (unless the build system changes, <osreldate.h> remains unchanged across kernel revisions, since /usr/include is not consulted in order to build kernels, per the original message). You can't possibly have a system component that reference <osreldate.h>, since it's not accessable in the kernel build environment (this is the problem he is talking about addressing). > Further still, there is the uselessness of __FreeBSD__ in some circumstances. That would be those vendor circumstances where vendors want all BSD's to standardize on the same interfaces. The fly in that ointment is BSDI, of course, since they are going to go their own direction, come hell or high water. > 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. It is related in terms of the date of the OS release compared to the date of the kernel. It is useful for a "feature test" only in the case of feature increase, never in the case of decrease. In a way, it is similar to a shared library minor revision number: you can add with it, but if you take away, all bets are off. > 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). It is a big mistake to break existing userland binaries -- including that supplied by third parties -- when you make a change to the kernel. Right now this is a problem because of the way libkvm works: the way the iteration interface works is dependent on the structure sizes, and they are not abstracted such that the code that iterates can do so independent of the structure size changes. This is a mistake in the character of the implementation of libkvm, and it's a mistake in coding in the user space programs which use libkvm. To act otherwise is to invite third party user space code to break when kernel changes occur. And that's what currently happens. The point of a kernel versioning stamp is to provide an <osreldate.h> style facility for third party kernel components, such as those distributed by OSS (the sound drivers). You can't expect kernel structures to not change. You *should* be able to expect that kernel interfaces not to change, and there should be *no* interfaces (for user space code, anyway) and *few* interfaces for kernel code, which depend on the size of kernel structures. > [...] > > 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 :). Good plan. That's the point of FreeBSD doing releases: to commit as large of its user base as it can to a particular set of interfaces, so that a third party developer can feel secure enough in their market that they will actually develope code for FreeBSD. Personally, I'd like to see the user space static enough that third party programs that want to manipulate system configuration interaces have to go through an interface which is held constant across the kernel/user interface changing. This means you use a library or you run probrams for which the interface is not going to change in order to, for example, manipulate the mount() system call. And FreeBSD makes no commitment whatsoever that that particular kerne/user interface is not going to change, only that you will still be able to system(3) the same "/sbin/mount" command with the same arguments, across revisions. Clearly libkvm is not an acceptable candidate for an interface which can be "frozen" like this -- you would ask FreeBSD to have no progress past the status quo. Your market would go away as people left FreeBSD just as surely as your market will go away if FreeBSD leaves an interface you depend upon behind without providing a revision-neutral alternative that you can depend upon (and which you *use*). Either way, your market is in danger until the interfaces are stabilized, either by way of compartmentalization, or by way of non-data abstraction (preferrably both, so that third party system component vendors get the same benefits as third party user space program vendors). In any case, making third party kernel module developement robust in the face of kernel interface changes in the mean time, is not a bad idea, and that's what a kernel version stamp seperate from the userland version stamp, will do. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704110018.RAA10243>