Re: CVS commit: src/sys/sys

["Joseph Koshy" <netbsd%jkoshy.net@localhost>]

On 2025-11-13 14:37 Robert Elz <kre%munnari.oz.au@localhost> wrote:
> Date:        Thu, 13 Nov 2025 14:02:12 +0100
>     From:        Jörg Sonnenberger <joerg%bec.de@localhost>
>     Message-ID:  <c807a6f5-eb9e-456b-913c-22a14e81c9e9%bec.de@localhost>
>
>   | [Me...]
>   | > That define is for internal kernel ABI changes (and should really almost
>   | > never be tested by anything in userland.)
>   |
>   | There is a lot historic precedence for using exactly this approach.
>
> Yes, I know, it has always been wrong, the kernel version is
> too crude to keep track of all changes that affect userland,
> and if we tried to make it so, we'd be bumping it every day,
> perhaps several times.
>
> This case is one of the less clear, az it affects a kernel include
> file, and so can be kind of assumed to be in sync with sys/param.h
> though why this particular definition is there rather than in
> tbe userland equivalent header which userland should be using
> (which includes the kernel one for the shared definitions) I have
> no idea - clearly the kernel doesn't use it, as no kernel changes
> were needed when it altered.

> But in general, we do not assume that userland is updated with
> every updated kernel, whether or not __NetBSD_Version__ changes.
> So using that define to guess at userland features can't in
> general be expected to work.
>
> We should, all, get used to dealing with this issue properly.
> Always make sure some compile time testable symbol changes
> whenever some feature visible to userland is added/removed/altered.

I am not sure that the approach of defining 'one feature flag
per significant API/behavior change' scales well over time.

FreeBSD uses a single number in <sys/param.h> to denote the
current 'frontier of development', across both the kernel and
userland [1], [2].  This number is incremented by 1 whenever
there is a noteworthy change to the system.

 [1]: https://docs.freebsd.org/en/books/porters-handbook/versions/
 [2]: https://docs.freebsd.org/en/books/porters-handbook/porting-dads/#porting-versions

Having just one number to look at simplifies application
porting -- because that number encodes, in a succinct way,
the same information as conveyed by a collection of
individual feature flags.

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

-- 
Joseph Koshy | Computer Scientist, Software Developer | https://jkoshy.net/