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

Pavel