From nobody Sat Dec 20 18:04:20 2025 X-Original-To: dev-commits-src-all@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 4dYXNX6zzqz6KfSJ; Sat, 20 Dec 2025 18:04:28 +0000 (UTC) (envelope-from glebius@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 "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dYXNX4JyMz3x9m; Sat, 20 Dec 2025 18:04:28 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1766253868; 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: in-reply-to:in-reply-to:references:references; bh=1LILDiBxX8Qu4ktnlhSllxzWfRJoIbCi10tIe9LFoow=; b=LLpZ1j4mHkCGcoi8qgIWaWnINlUC3gWNGpGoybqCvNdJJnPHMRgdjayYsZxu5hot55f5x0 F6j4yrV/Ab/BDQMArgm+tWwaMLKNCm857AulDbQBATYisK2myodCqeXmkhiW4PsPHhLDnV 2+x6bxSnnHTmgP0gegxVlSs6IJNTQOyneZ61x6QINB88cBzKbNXjTbFcRZ3omPjGKlkrDy ZppgYGGvSH5iZYkuYgaLEZbre3hEPZTBuek3CToPhl3aWORdF2I+MxpqTOyxQp6vwE63Io 6Z4dEiCM6Q54OOzihQrnQAFzS+EbEPBeyk96JffOhpqDNyiiJsCHeDZimFP4mQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1766253868; 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: in-reply-to:in-reply-to:references:references; bh=1LILDiBxX8Qu4ktnlhSllxzWfRJoIbCi10tIe9LFoow=; b=BvdFezrS5JN6xL9LLks0Siajnbjd3ry1M+1981LOywJyLbwdNgyb/tgUtuQKYqtU/ABlhP Sp3yxyBuk4Qp5O8LxZe4CaE//7URgKfMHPHRwVoWWGzODYYRgbNUEI9f9yX5rAHBZKcAva 9pNVYmPwErkNSb/ObPWqlzvu1YO43F+BD3msSCDMg/QS11s8v8DWd15DsCDKwhVIt73r2e f4oy+ot3eOg6efUuafjSa3n4OfTBiRsBkYRsgwvfDn5/m1f5TQcHFK+i/cZB2PlL9gh3xm ysE6b9HIazQP0VN9h10zQg8pvlV/JSA30eIslo1WO4V9Qn99Vz8Yt0HkZlNKDw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1766253868; a=rsa-sha256; cv=none; b=KO2CWFx7ra/YK11iF2KvCvoU6Yh873tY6aRKhwgDUDImR8ONiYLDYFBy98Q/7+GZ2EbzGu OUngeOu8v+ysWM95DGOXRfJiTEgg6ACRTMMptg8rFMzopv9cU5IX554/PRWrpDfsrNaCOo yfv55OXbFgUhA3pe+oMpvczrgzH5DW4v+sVmvgD28TBHKkUeBzm5W296t6cYtV9ZepX4A+ 40Syc3sP32w+ZoVjHiRbSrnFiIDsY/3zWUAx74izmLSjXj42Uclly3fZcIuczMufCDaGgU R7Zvf2CS2uVn+8hvJ4YE5zBNspPR7tgM5lrrzs6KMiwCYi8i5VTq3IX0Kn3tYQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from cell.glebi.us (glebi.us [162.251.186.162]) (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) (Authenticated sender: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dYXNT2tY4z1M29; Sat, 20 Dec 2025 18:04:25 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Sat, 20 Dec 2025 10:04:20 -0800 From: Gleb Smirnoff To: Konstantin Belousov Cc: Mark Johnston , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: e967a2a03677 - main - sockets: remove compat shim for divert(4) Message-ID: References: List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Sat, Dec 20, 2025 at 01:43:35PM +0200, Konstantin Belousov wrote: K> > K> > Those hypothethical binaries that we can't prove/refute existence of in some K> > K> > corporate environments would print a warning on 14.x and on 15.x providing a K> > K> > time to their owners to recompile. If we speculate that somewhere in the K> > K> > universe exists a corporate body that uses AF_INET/IPPROTO_DIVERT tuple in K> > K> > their internal software and have lost its source code, they have a solution. K> > K> > The solution is a tiny preloaded library that would intercept socket(2). Of K> > K> > course you may say that somewhere in the world exists a closed ecosystem that K> > K> > uses AF_INET/IPPROTO_DIVERT in a binary AND the sources for the binary were K> > K> > lost AND the binary is statically compiled. If you decide to go that deep into K> > K> > the rabbit hole, I would reply that owners of such a binary should bit hack it K> > K> > to use the correct tuple before call to socket(2). K> > K> No. You abruptly break binary compatibility and claim that this is fine. K> > K> It is not. K> > K> > Can you please elaborate what question are you answering with "No"? K> By 'no' I am reacting to the whole attititude of voluntaristically breaking K> the ABI guarantees that we, as the project, aim (or struggle) to provide. K> The citation above is self-illustrative in this regard: K> 1. Your change forces user to debug the broken application, so the user K> must have the detective skills. It is not quite trivial even to detect K> the cause of brokeness. K> 2. Then, the user must have dev skills to implement one of the workaround K> you listed (I would call them hacks). K> And all that trouble is for what? K> Do you think that the victim would do all that, or just abandon the idea K> of using an app? Really she must be quite dedicated to abandon the app and K> not the FreeBSD use. K> K> But this dialog directs the discussion in the invalid direction: if we as K> the project maintain ABI backward compatibility, it should not happen at K> all. ABI backward compatibility is not just a binary thing. There are different kinds of it. For example, if ABI for some standardized API has changed, we probably need to carry the ABI shim for a very long time, probably indefinite. Do you really insist that any API/ABI that was committed to FreeBSD should stay in it indefinitely? There were lots of ideas that were proved wrong and there were lots of code that was pushed non-polished. Later that was refactored with breaking ABI and API changes. If the project followed your strategy you would still stay with ipfw(4) functionality of FreeBSD 2.2.8 and I would still have a carp(4) "interface", ... I can continue this list. I can also ask are we allowed to completely remove certain interfaces or device drivers completely. Cause removing something definitely breaks compatibility. In my opinion ABI backward compatibility is not just a binary thing. Every particular case requires independent judgement. My analysis shows that expected negative impact of this change is close to zero, if not an absolute zero. I know that you didn't do any analysis, cause you pointed at python. The thing is that the python does know about PF_DIVERT and it never ever knew about IPPROTO_DIVERT. The change basically can't break python itself, only scripts that hardcoded value of IPPROTO_DIVERT internally. Your example with a hypothetical user that would abandon FreeBSD due to this issue doesn't buy me. At work I do routine updates of our software dependencies, and fixing internal code due to changes in curl, OpenSSL, etc and basically stronger compiler restriction is my monthly burden. But it doesn't make me abandon curl, OpenSSL or clang. K> I already said that in my first response. If you cannot tolerate having K> this in code you run, wrap the helper into COMPAT_FREEBSD15, and comment K> out this option from the kernel config locally. Of course COMPAT_FREEBSD15 will stay in GENERIC forever, right? -- Gleb Smirnoff