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

On 9/25/26 12:27, Jason Harmening wrote:
> On Fri, Sep 25, 2026 at 5:34 AM Christos Margiolis <christos@freebsd.org>
> wrote:
> 
>> On Wed Sep 23, 2026 at 10:19 PM CEST, Jason Harmening wrote:
>>> On Wed, Sep 23, 2026 at 2:19 PM John Baldwin <jhb@freebsd.org> wrote:
>>>
>>>> On 9/22/26 14:54, Jason Harmening wrote:
>>>>> Do you plan to also bump __FreeBSD_version__ for these changes?
>>>>> This will break any out-of-tree sound driver that uses these macros,
>>>>> particularly if you MFC it.
>>>>> Such drivers will then need some way to determine whether to hardcode
>> '1'
>>>>> or use the previous macro/hardcode '5' to avoid a failed dependency
>>>> check.
>>>>> I still maintain such a thing, however few users there may be, and it
>>>> seems
>>>>> unsafe to assume there aren't others.
>>>>>
>>>>> This seems like a completely unnecessary change TBH.
>>>>
>>>> Can you use #ifdef to test if they are defined in an out-of-tree driver?
>>>> In
>>>> your case, perhaps as something like:
>>>>
>>>> #ifndef SOUND_MINVER
>>>> #define SOUND_MINVER 1
>>>> #endif
>>>>
>>>> <replying-all this time, god I despise the gmail UI>
>>>
>>> Sure, I mentioned that very possibility in my post on
>>> https://reviews.freebsd.org/D59873.
>>> That's still a hack, and I'm still not sure why it was necessary to kill
>>> these defines in the first place.
>>
>> Does your driver actually depend on sound(4)'s versioning, and if yes,
>> how?
>>
> 
> Uh, yes...just like all the in-tree drivers before you made this change, it
> depended on those version constants to allow the module to load correctly.
> 
> Of course I get what you're really asking here, and no...just like the
> in-tree drivers, it does not make any functional distinction between
> different sound(4) versions.
> 
> 
>>
>> The reason for deleting those, although technically unnecessary, was
>> because these values have been forgotten for years and do not actually
>> mean anything useful, so I think it's better to just clean this up and
>> fix the few (if any) use-cases, than keep this rotting further.
> 
> 
> I completely understand that these no longer meant anything useful in terms
> of KPI/KBI compatibility, but I don't really see why getting rid of them
> was worth the churn, even just the in-tree churn (disregarding risks for
> out-of-tree drivers).  What ongoing maintenance burden were these defines
> likely to cause?
> 
> As a separate question, would it instead make sense to make these versions
> start meaning something again?
> For example, you recently made a change to require mixer_init() to be
> called in a certain order relative to other initialization.  That change
> seems perfectly reasonable from a technical standpoint, but would it also
> make sense to bump the version constants to avoid a panic from loading a
> stale audio driver kmod that didn't use the correct init sequence?

Actually, I think 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 (usually more often
than that).

I suspect what we probably should do is to take advantage of that a bit
and generally retire module versions.  Aside from the kernel module version,
I've never seen any module ever use distinct min/pref/max versions, and
it's kind of clunky.

I would suggest that we either abandon explicit module versions for all
modules but the kernel (just hardcode them to 1 in the various and use
cpp magic to define alternate MODULE_ macros that don't take the version
numbers), or instead reuse the same logic we use now for the kernel
module of using __FreeBSD_version values for other module versions (so
max is always __FreeBSD_version, and min can be the root of the branch
on stable branches).  However, I'm not sure the latter buys us very
much since it would just duplicate the kernel version anyway, so I would
lean towards the first approach.

BTW, in terms of Kevin's later question about version epochs, every
major version is already a new epoch, so resetting to 1 in main isn't a
big deal.  If we follow my suggestion above for module versions we would
effectively reset all modules aside from the kernel to version 1 forever.

-- 
John Baldwin