On Fri, Dec 19, 2025 at 10:07:37AM -0800, Gleb Smirnoff wrote: > On Fri, Dec 19, 2025 at 07:56:18PM +0200, Konstantin Belousov wrote: > K> On Fri, Dec 19, 2025 at 09:48:00AM -0800, Gleb Smirnoff wrote: > K> > On Fri, Dec 19, 2025 at 10:12:42AM -0500, Mark Johnston wrote: > K> > M> > > All known software in ports had been addressed three years > ago and the > K> > M> > > shim stays in stable/14 and stable/15 for another couple > years with its > K> > M> > > printf(), so all ourliers are expected to conform before > 16.0-RELEASE. > K> > M> > > See 8624f4347e8133911b0554e816f6bedb56dc5fb3 for details. > K> > M> > So why breaking the binaries that users might have lingering around? > K> > M> > K> > M> Aside from that, with a PF_DIVERT socket sd it's not possible to call > K> > M> sd.recvfrom() in python (because python doesn't know which sockaddr > K> > M> subtype to use), whereas with a PF_INET divert socket it gives a > K> > M> sockaddr_in with an interface address, for inbound packets. > K> > > K> > This means my submission to python back in 2022 was missing couple > lines. The > K> > Modules/socketmodule.c:makesockaddr() is missing a case. :( > K> > > K> > If people were not ignoring the warning message and switched to PF_DIVERT > K> > earlier, I would learn that my patch to python was missing a bit earlier. > K> > > K> > I will start a new submission to python. Usually they are very slow to > accept. > K> > I'm fine if you revert e967a2a03677. But let's plan to remove it before > K> > stable/17. > K> Why? > > Because 99.9999% socket() syscalls specify correct domain/type tuple but still > do this check. 99% FreeBSD's don't event have ipdivert.ko loaded or added to > kernel config. And out of 1% that uses divert, 99% specify correct PF_DIVERT > domain, cause all known software had been addressed. > > K> Apparently, the feature is widely used by applications. It is even present > K> in python. Breaking it is abrupt and must be reverted. > > First, I am not removing any features. The divert(4) feature only get better > with my changes back in 2022. Second, python also knows about PF_DIVERT since > version 3.12. As Mark noted the patch to python wasn't complete and I'm > working > on this now. So I'm fine with prolonging the compat shim, but not forever.
We are discussing different things altogether. I am saying that you are breaking binary compatibility, and asking why. I do not see a reason. It has no relation to the fact that there are other ways to get the same behaviour from the system. The removal of that three lines breaks existing binaries. Also it does not matter that e.g. newer versions of some apps do not use that feature (feature as in binary interface, not a system behaviour). The existing binaries must continue to work.
