Date: Sat, 20 Dec 2025 10:04:20 -0800 From: Gleb Smirnoff <glebius@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Mark Johnston <markj@freebsd.org>, 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: <aUblJN9InIhmdpZ8@cell.glebi.us> In-Reply-To: <aUaL5x-EIE58sjYM@kib.kiev.ua> References: <aTo89YdeZByEuZov@kib.kiev.ua> <aUVralcxtt3d8plJ@nuc> <aUWP0F-5QH5DMxZn@cell.glebi.us> <aUWRwsk5Xly_KLV5@kib.kiev.ua> <aUWUaawaU8RbsS_l@cell.glebi.us> <aUWuHb-l6SGV3CV-@kib.kiev.ua> <aUWy_L-wO0XcI5Do@cell.glebi.us> <aUW3pdfo1PvTgzDr@kib.kiev.ua> <aUW6tNuTDw-xM_tV@cell.glebi.us> <aUaL5x-EIE58sjYM@kib.kiev.ua>
index | next in thread | previous in thread | raw e-mail
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 Smirnoffhelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?aUblJN9InIhmdpZ8>