From owner-freebsd-hackers Thu Apr 10 16:16:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA07455 for hackers-outgoing; Thu, 10 Apr 1997 16:16:39 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA07450 for ; Thu, 10 Apr 1997 16:16:31 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA10047; Thu, 10 Apr 1997 15:56:07 -0700 From: Terry Lambert Message-Id: <199704102256.PAA10047@phaeton.artisoft.com> Subject: Re: detecting kernel version at compile time To: avalon@coombs.anu.edu.au (Darren Reed) Date: Thu, 10 Apr 1997 15:56:07 -0700 (MST) Cc: terry@lambert.org, proff@suburbia.net, hackers@FreeBSD.ORG In-Reply-To: <199704102253.PAA12112@coyote.Artisoft.COM> from "Darren Reed" at Apr 11, 97 08:47:09 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > In some mail from Terry Lambert, sie said: > > > > > Another benefit is that __FreeBSD_sysversion isn't necessarily > > > __FreeBSD_version i.e users may update their sys tree more frequently > > > than the rest (presuming they even have the rest of the source > > > distribution). > > > > > > Ability to detect the kernel version at compile time is essential to > > > adequately support third party modules. > > > > I agree... why is it that you always come up with good ideas? 8-). > > To quote Jordan "this is giving me a headache". > > As one of those third party developers, I don't have time for this > constantly changing crap. > > You are deceiving yourselves if you think you are just making life > easier for everyone. Any change implies more work from 3rd party > developers to accomodate that change. 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... > That work is probably many times what you perceive it to be because 3rd > party developers have to incorporate the new with the old and still keep > everything working. I'm aware of how a third party developer can put the "backword" into "backward compatability"... This particular change only allows the developer to do that, not the other way around. Read the original message which I responded to again: the change is to make a third party module stay working in the face of other changes, and to diagnose why it doesn't work in the case of a conflicting change. It won't affect the operation of third party modules. 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...). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.