Re: Can version bump up to 9.99.100?

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Fri, 23 Sep 2022 22:57:52 -0400
    From:        "David H. Gutteridge" <david%gutteridge.ca@localhost>
    Message-ID:  <c828c932f29b5fec01c2064be3505dff3d54ab0d.camel%gutteridge.ca@localhost>


  | Sometimes it's necessary to test for when a feature was added in a
  | -current release, and there's no simple or precise way to do it, as
  | you've noted. If a feature was added sometime in xx.yy.zz, then a test
  | might (retroactively) be expressed with zz+1 as the floor.

Yes, I know.   But if a feature is added then there ought also be some
better way added to test that that has happened, not the kernel version.
If that doesn't happen, people (that's us) should complain, and make it
happen.

For kernel changes, testing the kernel version has at least some kind of
rationale behind it, though the x.99.abi bump scheme doesn't generally
fit well, as the abi bumps almost never happen for new features - there
could be months (or longer) pass before the abi value is altered.

When the change isn't to the kernel, but relates to something changed in
userland, testing the kernel version is 100% useless (and often wrong).
(And yes, that includes anything that uname outputs, or any other kernel
supplied information that wasn't previously set by userland).

The really hard case is where a kernel bug (eg: an ioctl not working
correctly) is fixed, which has been worked around, but no longer needs
to be afterwards.   An example might be the O_NONBLOCK on pty master
devices that just got changed.  This kind of thing will generally not
require a kernel abi bump (and could also happen in x.n (like 9.2 over 9.1)
as well, and appear in x.n_STABLE along the way) and very often requires no
other changes other than to the code in the kernel source file(s) concerned,
so there really is nothing to test.

An idea might be to add some new sysctl var (for kernel changes only)
that gets bumped far more frequently (every time something new is added,
or some user noticeable bug gets fixed (ie: not whitespace, KNF, spelling
errors in comments, changes to printf output....) and is perhaps reset
whenever a __NetBSD_Version__ bump occurs (and this would apply in both
stable and HEAD versions) so that there is a more precise way to test for
this kind of thing (including looking to see if running a version that had
a bug temporarily imported, by knowing (with hindsight) the value of this
var before the bug was added, and when it was later fixed).

Alternatively, perhaps only reset for new netbsd-N branches (so 10.0 would
start again at 0, as soon as branched, and HEAD which will become 10.99.0
will also revert to 0 at that time) and otherwise simply both climb (an
unbroken sequence through 10.1 10.2 ... 10.17 ...) until we branch -11
where 11.0 would start at 0, and 11.99.0 would as well (but 10.whatever
would just keep climbing, until EOL).

This ought to be a potentially BIG number (something we can never run out of
in any practical situation), but just a simple integer, so it probably would
not, ever go past 6 or 7 digits, but we don't want to ever worry about the
possibility of overflow so an int64_t or similar, a bump should just be a ++.

It also ought live in a source file of its own, depending only on the header
file which declares it for the sysctl routines that export it (in some other
file, where that is doesn't matter) so changing its value is cheap, and
no-one will be reluctant to do it.

Cheap particularly wrt the cost of builds after it is altered - unlike
__NetBSD_Version__ which, being in param.h, causes almost every file in the
kernel to need to be recompiled when it is altered, even though almost nothing
in the kernel cares in the slightest what value it has (just a few things here
and there).

This tiny (3 line - one comment, one #include, one var decl - plus copyright
noise) file could even be MD, so the version numbers for one port don't
affect others (a change to an x86 private function, need not show up as a
change that is visible on sparc systems) - or we could have 2 variables,
one MI for changes that affect everyone, and one MD, for the others, and
return both of them from one sysctl.   Or this might just be too much
complexity, a single number shared by everything would also work, and
is what I think I'd prefer.

Kernel commits would then note what this value has been bumped to for the
change (when the change is one that requires it - and the rule should be:
if in doubt, bump it, it is cheap).

How to test new features / fixes for userland, I'll leave to others to ponder.
(also, here, this is tech-kern).

kre