From nobody Sat Sep 26 14:19:19 2026 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4hsV7h35z1z6t9RY; Sat, 26 Sep 2026 14:19:28 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [66.216.25.90]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4hsV7g4cFYz50k6; Sat, 26 Sep 2026 14:19:27 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=softfail (mx1.freebsd.org: 66.216.25.90 is neither permitted nor denied by domain of jhb@FreeBSD.org) smtp.mailfrom=jhb@FreeBSD.org; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=freebsd.org (policy=none) Received: by mail.baldwin.cx (Postfix) id F07571DE85; Sat, 26 Sep 2026 10:19:19 -0400 (EDT) Message-ID: Date: Sat, 26 Sep 2026 10:19:19 -0400 List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: git: 32137c41065c - main - sound: Retire the version constants Content-Language: en-US To: Jason Harmening , Christos Margiolis Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org References: <6ab2bc22.412bd.10bb456f@gitrepo.freebsd.org> <2df20868-4983-4169-a94e-da6adf2fb3ea@FreeBSD.org> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.4 (mail.baldwin.cx [0.0.0.0]); Sat, 26 Sep 2026 10:19:20 -0400 (EDT) X-Virus-Scanned: clamav-milter 1.5.2 at mail.baldwin.cx X-Virus-Status: Clean X-Spamd-Bar: / X-Spamd-Result: default: False [0.20 / 15.00]; ONCE_RECEIVED(0.20)[]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : No valid SPF, No valid DKIM,none]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[jhb]; ASN(0.00)[asn:19151, ipnet:66.216.0.0/18, country:US]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[dev-commits-src-all@freebsd.org,dev-commits-src-main@freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ALIAS_RESOLVED(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4hsV7g4cFYz50k6 On 9/25/26 12:27, Jason Harmening wrote: > On Fri, Sep 25, 2026 at 5:34 AM Christos Margiolis > 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 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 >>>> >>>> >>> >>> 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