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
identifier.

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.

Pavel