Re: git: 32137c41065c - main - sound: Retire the version constants

On 10/1/26 10:39, Jason Harmening wrote:
> On Mon, Sep 28, 2026 at 8:13 AM John Baldwin <jhb@freebsd.org> wrote:
> 
>> On 9/26/26 13:37, Jason Harmening wrote:
>>> I'd definitely agree on getting rid of the min/max/pref distinction and
>>> just having a single version.
>>> It's always seemed like a stretch to imagine any dependent module making
>> a
>>> meaningful distinction between those 3 versions in a way that wouldn't be
>>> extremely fragile.
>>>
>>> Ideally, some form of module-specific versioning still seems useful for
>>> addressing scenarios like the mixer_init() case I described above.
>> Bumping
>>> the global version for cases like that seems very heavy-handed, though
>>> maybe it wouldn't be such a big issue in practice, or maybe some of the
>>> recent suggestions for consolidating those version bumps could be useful
>> in
>>> cases like this.
>>
>> We already use __FreeBSD_version to mean there is a KPI or KBI change.  I
>> also
>> think the recent thread on bumps was a bit exaggerated.
>>
>> Here's some data vs anecdotal "we bump too much" feelings:
>>
>>> git log --first-parent -G __FreeBSD_version --format=%cs sys/sys/param.h
>> | uniq -c | head -30
>>      1 2026-09-14
>>      1 2026-09-09
>>      1 2026-09-06
>>      1 2026-09-05
>>      1 2026-09-02
>>      1 2026-08-27
>>      1 2026-08-12
>>      1 2026-06-19
>>      1 2026-04-30
>>      1 2026-04-25
>>      1 2026-04-23
>>      1 2026-04-06
>>      1 2026-03-21
>>      1 2026-03-12
>>      1 2026-02-13
>>      1 2026-01-25
>>      1 2026-01-23
>>      1 2026-01-16
>>      1 2026-01-13
>>      1 2025-12-18
>>      1 2025-12-15
>>      1 2025-12-09
>>      1 2025-11-02
>>      1 2025-10-30
>>      1 2025-10-21
>>      1 2025-09-29
>>      1 2025-09-04
>>      1 2025-08-18
>>      1 2025-08-17
>>      1 2025-08-16
>>
>> As you can see, we've yet to have multiple bumps on a single day in the
>> past year (which I
>> agree should be avoided), but bumps are also rather sporadic.  We have a
>> few weeks a year
>> where they cluster (multiple bumps in a week), but we also have entire
>> months without a
>> single bump.
>>
> 
> If version bumps are that sporadic, then that sort of works against your
> earlier argument that "module versioning has mostly been made meaningless
> for most modules since we depend on the kernel version using
> __FreeBSD_version, and we already bump __FreeBSD_version for KBI
> breaks...".  It doesn't seem to be at all guaranteed that there will be a
> global version bump "soon enough" to render a localized module version bump
> meaningless or unnecessary, unless we start requiring a global version bump
> for even things like the mixer_init() example above whose scope is limited
> to a specific subsystem kmod and its dependent kmods.  My point above is
> that this seems unnecessarily heavy-handed, since it breaks KBI versioning
> for all kmods.  I agree that it probably would be tolerable in practice,
> but it does not seem to be something we do consistently in such
> localized-scope cases today.

My suggestion indeed is that for actual KBI breaks that matter, one should
just bump __FreeBSD_version.  The subsystem-specific scheme that we've had
for 25+ years hasn't proved useful in practice.  My assumption is that
is because it is overly complex, so we should instead just use a simpler
solution even if it's a broader hammer as this approach might actually get
used.

My point about the data above is that a few more bumps are not going to be
an end-of-the-world apocalypse.

> In any case, my goal in starting this thread wasn't to have a discussion
> about coming up with a better module versioning scheme, it was to simply
> ask that more consideration be given to avoiding changes that gratuitously
> break driver modules.

Hmm, I guess the trick is what counts as gratuitous which is fairly
subjective.  The policy I've tried to follow when refactoring APIs used
by out-of-tree drivers is to provide compat shims when possible to allow
the "new API" and "old API" to coexist for at least one major version and
to remove the shims for the "old API" in the next version.  In that case I
tend to MFC shims for the new API back to stable branches so driver
writers have a fair bit of latitude of when to update.  Sometimes that
isn't as easy to do (the pmap ones I did in main earlier this year I could
not shim, and so they were only done in main and will not be MFCd).

However, it is also fair game to use #ifdef on other macros than just
__FreeBSD_version to detect an API change at build time.  I've done this in
several places in GDB to handle ptrace() API changes by checking for the
relevant macros for the new API rather than comparing versions.  I kind of
feel like this falls into that type of case.

-- 
John Baldwin