Re: CVS commit: src/sys/sys

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

    Date:        Mon, 17 Nov 2025 08:47:58 -0700
    From:        Warner Losh <imp%bsdimp.com@localhost>
    Message-ID:  <CANCZdfqvT3-a-Fv1-LLTK4-+N3C81QY5-OwQ5VyZ=M+Y4YGNYg%mail.gmail.com@localhost>

  | I don't follow why the guard needs to be there forever. It's in
  | implementation
  | namespace and can therefore be removed or renamed at any time.

Sure, it could, but why would anyone want to bother with either of those?


  | Nitpicking over spelling isn't helping win me over.

That was just me making sure that we understood that the symbol is
in the implementation namespace, which as you said earlier in your
message:

	It's in implementation namespace and can therefore be removed
	or renamed at any time. It's an implementation detail, but it's
	not one people can rely on.

but you seem to be suggesting (or supporting) using that, in preference
to some other (also implementation namespace) name, because the latter
might get changed or removed, which makes no sense to me.

  | If I were to make everything #pragma once and remove the guards,
  | NetBSD would compile just fine.

Sure, assuming you're using a compiler that happens to implement
the #pragma the way you expect it to be implemented.  As best I
can determine, none of the #pragma operations that compilers
implement (other than the very few STDC ones, which aren't at all
useful for this purpose) are standardised at all - compilers are
largely free to do whatever they like.

On the other hand #define and #ifdef are standard (and have been
around forever) and the way they work is very much standardised.

In NetBSD we prefer to write portable code as much as is possible,
so replacing include guards using define&ifdef with a pragma which
might, or might not, work, seems like an absurdly ridiculous thing
to even suggest, let alone bother to implement.

  | I've used FreeBSD for 30 years, and we've done this there for 25
  | of those years. None of these issues are real problems. In fact,
  | we use the version to detect mismatches between the kernel and
  | userland so we can report both versions.

In FreeBSD itself, I'd expect that, certainly, what bothers me more
is how external code developers, trying to support their code on
FreeBSD cope with this.


  | FreeBSD's V also encodes the major and minor versions, so the
  | whole scenario is avoided. You get unique numbers that you can easily
  | test for.

OK, that was the second of my three possible approaches to this (and
which suggests that the earlier report I saw of how it worked was at
best, extremely simplified).

For that, no question, tests can be written, and made to work, but
were I an external developer, I'd just say "no FreeBSD support" when
someone told me I was supposed to attempt to deal with that, which
would mean embedding something like (note, I have no idea of how
the encoding is actually done, so I may have lots of details wrong,
but I think this at least is kind of 

#if defined(FreeBSD) && ((V > 50201vvv & V < 50201vvv) \
			 || (V > 50300vvv && V < 60000000) \
			 || (V > 60000vvv && V < 60100000) \
			 || (V > 60100vvv && V < 60200000) \
			/* continues like this for every minor version */
			 || (V > 10000000))   /* all versions after 10 are */
/* the fixed FreeBSD version code is here */
#else
/* dealing with older broken code is here *.
#endif

Note in that each use of "vvv" is independent, and represents which 'V'
(from the previous mail) is the appropriate one for that version, the
first test indicates a fix that was in 5.2.1 for a while, then removed
again, the others show where a fix was added to each old release, assuming
it remains after that, so it was added in 5.3.0 sometime, and in 6.0.0
and 6.1.0 sometime, and then is in every version from 10.0 onwards.

That kind of thing is just way too ugly for me (as this imagined external
software developer) to keep track of - let alone work out what all of those
version numbers are supposed to be.

In contrast, for the system I'm proposing, there is exactly one test,
which works exactly the same way, for every version of NetBSD, past and
future (but of course, only for future changes - one already made in the
past need to live with however they happened to be done).

All that's needed is to test that it is NetBSD, and that the particular
specific envioronment version number is up to (or perhaps within the
range of) when a specific fix was implemented - for that particular
functionality.

  | This makes no sense to me.

Sure, because all that was assuming that perhaps FreeBSD had adopted a
"no pullups of source breaking changes" rule, as I couldn't really see
how an endless stream of different version number sequences, one for every
release version of FreeBSD can possibly be tolerated by the outside world.
Inside FreeBSD it is easy though, that I understand.

  | With all software, it evolves, things break, unbreak, and weird stuff
  | happens.

Yes, of course.

  | With the version bump you can know what to do.

After you determine what the underlying issue is of course, that's
always the first step.   Having done that, the "you" in question must
then scan the bump docs for every FreeBSD version they're trying to
support (whether or not FreeBSD still support that version - users keep
running old stuff sometimes more or less forever - there's one NetBSD
user who keeps running NetBSD 1.4, which is from sometime c.2000 I think)
and try to find which particular version bump number for each FreeBSD
version makes the change that matters to them (and whether any later
version bump made other changes to that) and turn all that into the
kind of expression shown above.   Certainly possible, but if that "you"
happens to be me, I'd just instead add

#ifdef FreeBSD
#error OS Not Supported.
#endif

With what I'm proposing, which is still a version bump, just a very
specific one, when finding the cause of the issue, examination of
the header file which specifies the interface will be needed (in
our case, "why is the code trying to extract a field from a variable
(or field in a struct, or wherever it occurs) which is an integer?"
Looking at the header shows it is an integer, but the existing code
is clearly expecting it to be a struct.   Then just go to the start
of the header in question (beyond all the licence crud) and look at
the comments which will (or should) explain exactly what changed, and
which version of this file made that change (version not in the VCS
sense, but a #define in the file).

  | If you rely solely on the programmer adding this or that define and then
  | trying to base stuff off that, you wind up with trouble when items
  | are added to structures: there's no compile time way to effectively
  | detect that.

No, but if a field is added to a struct, then the header which defines
that struct can have its version number incremented, and that's trivial
to detect at compile time.

I suspect you're imagining something different than what I am proposing.

It is still version numbering, just finer grained than one sequence of
version numbers for everything in this OS version (and is independent of
OS versions, since those are half marketing nonsense - even open source
has that - and half reflecting where the ABI remains stable, and what
whole new features have been added).


  | https://docs.freebsd.org/en/books/porters-handbook/versions/

I have just skimmed that, and frankly, were I developing software that
I might want to have run on FreeBSD, I'd find that completely useless.

To give just one example:

	1300001		339730	October 25, 2018

the version number, git (I assume) revision ID, and the date it happened
that's all fine [well personally, I'd prefer rational dates: 25 October 2018.]

Then the explanation of why the version bump:

	13.0-CURRENT after bumping OpenSSL shared library version numbers.

WTF am I supposed to do with that?   OpenSSL version numbers bumped from
what to what?  And why was that bump made - what changed that made it
necessary?   That information is simply useless, and from what I can see,
aside from some clearly internal kernel only changes (which should be
irrelevant to me as a presumed userland code developer) that one is just
about as good as it gets (but note, I didn't read much further down the
list than that).

Now I'm sure I could go look at the log entry for that particular revision
and see what that says about that change, and hope that it is somewhat
more revealing, but at this point I have no idea whether or not this change
is at all relevant to the problem I am encountering - which must exist or
I wouldn't be looking at all.   Would I be willing to do that, for that
version, and lots of others?   I very much doubt it.   If it was Linux,
MacOS, or Android, with millions of users around the world, maybe - FreeBSD
(or NetBSD even less), not a chance really, it wouldn't be worth my time.

kre