Re: CVS commit: src/sys/sys

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

    Date:        Sun, 16 Nov 2025 15:13:04 +0100
    From:        Martin Husemann <martin%duskware.de@localhost>
    Message-ID:  <aRnb8HKwbEnuOSyT%master-of-confusion.duskware.de@localhost>

  | On Sat, Nov 15, 2025 at 09:43:59PM +0000, Joseph Koshy wrote:
  | > I am not sure that the approach of defining 'one feature flag
  | > per significant API/behavior change' scales well over time.
  |
  | That was not what was suggested (IIUC).

Indeed it was not.   What I suggested was one version identifier per
"facility" (or more likely, header file) - which would be incremented
when changes requiring code to be altered were made (other than removing
a #define - which can be tested just by looking to see if it is defined).

That's actually usually quite rare, the common case is changing the
signature of a function declared in the header, though changing a type
from being a struct to an int (int type) would count as well.

  | > So just incrementing __NetBSD_Version__ (by small values)
  | > could suffice perhaps?

There are (probably) enough minor versions in HEAD's version numbers
to allow that to work (ie: the N.99.vvv version numbers), there really
aren't in any released version (and no-one ever wants to alter those
anyway).   Doing it that way would prevent any kind of pullup to -11
for this change, which otherwise (assuming that all the ELF related
changes get finished in time) would not be unreasonable to do.

  | I personally like Robert's suggestion to deal with it local in the
  | header that changed a lot

Which also means that code which is affected by this already has the
header included (or it wouldn't be affected) - to use __NetBSD_Version__
code needs to include <sys/params.h> which cannot just unilaterally be
done, as it isn't a standard header (really, almost nothing in userland
should be including it, ever - it is kernel parameters, not userland ones).

  | So in general a solution along Robert's suggestion would have been good,
  | but the big hammer (__NetBSD_Version__ abused) works too (and now can't
  | be undone).

We can't undo the rev bump, but that (once) is relatively harmless.
But we can still do it the other way for ELF using applications to use
(like the ones from pkgsrc that mrg@ pointed out).

What's more, I have since realised that we don't need to invent a new
name for this - we have one of those available already - the include
file's multiple inclusion guard.   Currently those are simply defined
(no value) - but there's no reason they can't be given one.   So what
I am planning to do is change

	#define _SYS_EXEC_ELF_H_

in <sys/exec_elf.h> to be

	#define _SYS_EXEC_ELF_H_ 2

and then code which needs to distinguish the new and old ways to
get the Elf32_Versym  (or the Elf64 one) can be written like

#if defined(_NetBSD) && ((_SYS_EXEC_ELF_H_ + 0) < 2)
	/* do it the old NetBSD only way */
#else
	/* do it the new NetBSD way, the same as everyone else does it */
#endif

Because _SYS_EXEC_ELF_H_ has been defined (more or less) forever - that is,
from version 1.1 of that file from 1995, there's no need to test whether it
is defined, which a newly invented name would need, if it is NetBSD, it is.

kre