On Fri, Dec 19, 2025 at 12:51:00PM -0800, Gleb Smirnoff wrote: > On Fri, Dec 19, 2025 at 10:37:57PM +0200, Konstantin Belousov wrote: > K> > K> It has no relation to the fact that there are other ways to get the > same > K> > K> behaviour from the system. The removal of that three lines breaks > existing > K> > K> binaries. Also it does not matter that e.g. newer versions of some > apps > K> > K> do not use that feature (feature as in binary interface, not a system > K> > K> behaviour). The existing binaries must continue to work. > K> > > K> > We already have had this argument before for a different kind of issue - > K> > POLLINIGNEOF. The existence of such binaries is like existence the the > God. > K> > You can't prove they exist. I can't prove they do not exist. You > advocate for > K> > the compat shim to exist forever. I advocate to limit it existence to > some > K> > countable number of years. > K> > > K> > For this particular case all open source software had been addressed. > There > K> > are no known shareware binaries in the wild that used > AF_INET/IPPROTO_DIVERT. > K> I do not understand this statement. It was demonstrated in this thread > K> that python had it. > > Python itself doesn't use divert(4). It allows scripts to open the divert > sockets using constants instead of numbers, that's all. It is not the python > but legacy scripts that use the old PF_INET/IPPROTO_DIVERT tuple that need > adjustment. > > Python knows PF_DIVERT constant since 3.12. In our ports it is patched to > know > PF_DIVERT for all possible versions in ports. > > What Mark pointed out is that python's support of PF_DIVERT is not complete, > wrt recvfrom method. I'm working on fixing it. > > I'm fine with prolonging existence of the shim until python 3.11 goes out of > support, which is 2027-10. You clearly misunderstand what ABI compat is. Whanever the specific version 'goes out of support', there are still binaries which must continue to work.
> > K> > Those hypothethical binaries that we can't prove/refute existence of in > some > K> > corporate environments would print a warning on 14.x and on 15.x > providing a > K> > time to their owners to recompile. If we speculate that somewhere in the > K> > universe exists a corporate body that uses AF_INET/IPPROTO_DIVERT tuple > in > K> > their internal software and have lost its source code, they have a > solution. > K> > The solution is a tiny preloaded library that would intercept socket(2). > Of > K> > course you may say that somewhere in the world exists a closed ecosystem > that > K> > uses AF_INET/IPPROTO_DIVERT in a binary AND the sources for the binary > were > K> > lost AND the binary is statically compiled. If you decide to go that > deep into > K> > the rabbit hole, I would reply that owners of such a binary should bit > hack it > K> > to use the correct tuple before call to socket(2). > K> No. You abruptly break binary compatibility and claim that this is fine. > K> It is not. > > Can you please elaborate what question are you answering with "No"? By 'no' I am reacting to the whole attititude of voluntaristically breaking the ABI guarantees that we, as the project, aim (or struggle) to provide. The citation above is self-illustrative in this regard: 1. Your change forces user to debug the broken application, so the user must have the detective skills. It is not quite trivial even to detect the cause of brokeness. 2. Then, the user must have dev skills to implement one of the workaround you listed (I would call them hacks). And all that trouble is for what? Do you think that the victim would do all that, or just abandon the idea of using an app? Really she must be quite dedicated to abandon the app and not the FreeBSD use. But this dialog directs the discussion in the invalid direction: if we as the project maintain ABI backward compatibility, it should not happen at all. > > If you think that my deprecation was too abrupt, can you please suggest your > deprecation plan? I already said that in my first response. If you cannot tolerate having this in code you run, wrap the helper into COMPAT_FREEBSD15, and comment out this option from the kernel config locally.
