Subject: kern/36918: NetBSD 4.0_RC1 __NetBSD_Version__ botch
To: None <email@example.com, firstname.lastname@example.org,>
From: None <kre@munnari.OZ.AU>
Date: 09/05/2007 14:40:00
>Synopsis: NetBSD 4.0_RC1 __NetBSD_Version__ botch
>Arrival-Date: Wed Sep 05 14:40:00 +0000 2007
>Originator: Robert Elz
>Release: NetBSD 4.0_RC1
Prince of Songkla University
System: NetBSD jade.coe.psu.ac.th 3.99.15 NetBSD 3.99.15 (GENERIC-1.696-20060125) #8: Wed Jan 25 04:59:39 ICT 2006 email@example.com:/usr/obj/current/kernels/JADE_ASUS i386
The value defined (in <sys/param.h>) for __NetBSD_Version__
is incompatible with the __NetBSD_Prereq__() macro (also in
IMO this is a release blocking PR.
(Also note this is a branch specific bug, there is
no similar problem in -current, nothing here can be
corrected by any kind of pull up).
Build an LKM (or other similar object).
In it, do something like
#if __NetBSD_Prereq__(4,0,0) /* require NB 4.0 or lower */
/* whatever code */
and compile that on a 4.0 RC1 system. Watch it fail
(that is, 4.0 RC1 is an "advanced" system over 4.0).
All that can be done that will work is
#if __NetBSD_Prereq__(4,0,1) /* require NB 4.0.1 or lower */
/* whatever code */
but that will continue to work with NetBSD 4.0.1 which doesn't
exist yet (no-one can possibly write code that is guaranteed
compatible with 4.0.1 - not today).
There are two possible fixes that are plausible that I can
The first is to alter __NetBSD_Prereq__() and give it a 4th
parameter that would specify the largest value that is OK
in the final two (used to be MBZ) digits of __NetBSD_Version__.
That would be, of course, a LKM incompatoble change (an API
change - and a needed one, as current code cannot be correct)
which would because of that require a bump of __NetBSD_Version__
The alternative is simply to bump __NetBSD_Version__ to a value that
actually works with __NetBSD_Prereq__ - the smallest value that
fits (which is at least 400000003 - the current value of
__NetBSD_Version__) is 400000100 - which indicates NetBSD 4.0.1
(or 4.0.1 RC1 or anything else like that)
That's what I suggest doing. Release 4.0.1 instead of 4.0.
The only real issue is the timing - if it looks fairly certain
that no more version bumps will be required, then do it now.
If it seems likely that there might be some other change that
would require a version bump anyway, wait for that (or until
it is clear there will be no such event before the release).
It would be good to have a PR category "release" or something
for bugs specific to release candidates (Beta and RCs) - that is,
for bugs which occur only in those are aren't in any mainline code.