Subject: Re: __NetBSD_Version__ and stable branches
To: Greg Troxel <firstname.lastname@example.org>
From: Pavel Cahyna <pavel@NetBSD.org>
Date: 11/11/2006 14:57:17
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.
decoupling those two (release identifier and ABI identifier) could be
done in two ways: continue using __NetBSD_Version__ as ABI identifier
and use something else as release identifier (what I've proposed) or
continue using __NetBSD_Version__ as release identifier and use
something else (your proposed __NetBSD_KABI_Version__) as ABI
Apparently, most of __NetBSD_Version__ uses in our tree check for the
kernel API or ABI version, so it seems more reasonable to keep this
meaning for it. IMO most code does not have a reason to be
interested in release naming, and __NetBSD_Version__ does not express it
accurately anyway (it lacks the _BETA, _RC and so on tags).
> 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.
Even on -current, the macro is changed needlessly when a release
branch is started, e.g. 399002400 -> 499000100. Thus, I would
prefer a more radical change: not keeping is as-is even for -current
and making it completely independent of release naming.