Re: CVS commit: src/sys/sys

[Warner Losh <imp%bsdimp.com@localhost>]

On Sun, Nov 16, 2025, 3:28 PM Robert Elz <kre%munnari.oz.au@localhost> wrote:

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

But now you are committing to have this forever, even though it's not in
the documentation or the user's namespace. It means you can never do a
#pragma once sweep all over the tree, for example. And nobody is going to
notice at commit when they do this if things break since they will be out
of tree. With netbsd_version bumping, you don't have those issues. It seems
overly complicated for little to no gain. That system works great in
FreeBSD land: people are able to directly test to since all the bumps are
documented, and out of tree authors have one place to look for a workaround