Subject: Re: __NetBSD_Version__ and stable branches
To: Quentin Garnier <firstname.lastname@example.org>
From: Pavel Cahyna <pavel@NetBSD.org>
Date: 11/12/2006 14:54:18
On Sat, Nov 11, 2006 at 03:51:47PM +0100, Quentin Garnier wrote:
> On Sat, Nov 11, 2006 at 09:22:13AM -0500, Greg Troxel wrote:
> > I propose to decouple those two and make __NetBSD_Version__ only an
> > indicator of the kernel ABI, completely independent of the version
> > reported by "uname -r".
> > I think this could be confusing. Your problem is caused, in my view,
> > not by the __NetBSD_Version__ value being wrong -- your system did
> > indeed change from 3.0 to 3.1, but by the lkm machinery interpreting
> > system version number as a kernel ABI version.
> > So, perhaps we should introduce __NetBSD_KABI_Version__ and leave it
> > at 300000000 on netbsd-3, and keep changing it as we do for current.
> > I realize my comments can be viewed as nitpicking over name choices.
> > Your proposal of keeping the variable as-is for current and not
> > changing it along the stable branch (where KABI changes are
> > prohibited) seems very reasonable.
> Note that sometimes, __NetBSD_Version__ is used for API versioning,
> too. I'd like to see a __NetBSD_KAPI_Version__ also, one that would
> be maintained.
OK, so let's have __NetBSD_KABI_Version__ and __NetBSD_KAPI_Version__,
both independent of uname -r. As __NetBSD_Version__ is used for
API versioning now, lets add
#define __NetBSD_Version__ __NetBSD_KAPI_Version__
for sources which use it (e.g. IPFilter).
The values of __NetBSD_KABI_Version__ and __NetBSD_KAPI_Version__ could
be even split in "minor" version (incremented when something is added)
and "major" version (incremented when something breaks compatibility).