From nobody Thu Oct 01 21:08:43 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 4hwkzc3pC8z6tTr9; Thu, 01 Oct 2026 21:08:44 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "YR2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4hwkzc3HPMz4JZ7; Thu, 01 Oct 2026 21:08:44 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1790888924; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3CyBHcTGZoDo9IKz43yz4LdE1MAtLB8HJxStelGiJ4E=; b=pVHYp2MfHxA+GyebElDddJMX5m0VCQYpyKiKJOfD/tWzfrlAB/pzsCpyQvB/2jp+iFSHdg DyrqV/shyEqHXYgd3A5Tyn/zkrcJ2BgHEQUJVDDZ05n+Nd8k+zpxu9cQPKstWC3PnXROhV Ucp1YM2OpsDoln8tZsKjqCqyzRvjPTl06whs5BHf34CS2j3/GRK/8wmYwa5rZV3IjiiOnj K/38/tSMSTrXDIrCm6Tz/rUQMhXVglj67LLMQ9i74n4KthRsB12MzilLJLNZEELV/MDE7v DTLcuTIbv8QDkE+/u/f9St7HE9s3jaittD/G0x9hjMuZDxP4SgRSr/Ld9reBsg== ARC-Seal: i=1; a=rsa-sha256; d=freebsd.org; s=dkim; cv=none; t=1790888924; b=OzHD8rYjgUY5zhWWZ7VAx1LDmPB3MpqzHIwSwS+Rvb0m2r3iDjVmTPxZ6FMe1cLGjI0sVP jeT76UTyOwTKwbQJTb73pmT9ht5Wg+GCdmIdJtAQLPJRvlyhk5f9aMwaiqd8s8D8AmHkqf 8hjrVnyxzC5Br5wfb8P+55wLZ2KtEfJqR/F37G97y5LzPI0kGDRrmNA3qpK6pGZy9kK6XG fVAD0J6s5czu50frX+0566+7PNSZ8FGpSzRz1ISvhFxf7DWYh77snm8KEPFnOh0Q6z97FO /T0tpi317x44y66zvLVAQrjb2HL6IoE+jv0jMNKsETrCTNlxbkw0L40GI21v8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1790888924; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3CyBHcTGZoDo9IKz43yz4LdE1MAtLB8HJxStelGiJ4E=; b=jcWoT8qtDx2wyS1IFLIcCqjLl+GSWB1AYcth9GopBsX7m0g+k8XUIzI4FW1nER71T+eVvq XKmKpHDLULPMyCd+N9XXWYJtpjY7wTazAK44Lr90HIYtHLWkXaGKZUfm9GeVdG+P/52sV/ S+jG5CnRXiXnt3k6CGjQgBf5MxXkfplhWc5RbVnfGRW66IRLyT3UYrslUziBaU3ETUAMLr hD6g5NqsUl0DjpvwF7Dz5R6+b/rF4agZHbnARfrJZ5Z0ywMu/jFNBVcHk5HOj9+3weWD0p 4EQHCXQfeK/a4pF7REPERlmq1mjgWp3T0YL/eMnWsPeBJeYpnr74qaWPKQczGw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [IPV6:2601:5cc:4402:82e0:bd52:af18:5036:3121] (unknown [IPv6:2601:5cc:4402:82e0:bd52:af18:5036:3121]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4hwkzc0gk7zYkB; Thu, 01 Oct 2026 21:08:44 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <8ecda432-8a6f-46b3-b4f3-2a5761404b59@FreeBSD.org> Date: Thu, 1 Oct 2026 17:08:43 -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 Cc: Christos Margiolis , 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> <6280fdf4-0254-4953-b948-b6bac7796f80@FreeBSD.org> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 10/1/26 10:39, Jason Harmening wrote: > On Mon, Sep 28, 2026 at 8:13 AM John Baldwin 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