Date: Sun, 21 Dec 2025 15:31:00 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Gleb Smirnoff <glebius@freebsd.org> 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: <aUf2lFzR2VbaBwqd@kib.kiev.ua> In-Reply-To: <aUblJN9InIhmdpZ8@cell.glebi.us> References: <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> <aUblJN9InIhmdpZ8@cell.glebi.us>
index | next in thread | previous in thread | raw e-mail
On Sat, Dec 20, 2025 at 10:04:20AM -0800, Gleb Smirnoff wrote: > 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? Yes, once it hits the stable branch. This is the guarantee for the branches, and otherwise their existence is pointless. > 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. First, please do not mix API and ABI (and then KBI as well). Your point is right, but its interpretation should different: the premature ideas must not be added to the source tree. If something not that good was added to HEAD, it must be reverted before a next stable branch is created, otherwise it indeed stays there forever. > 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. Note the 'A' in the ABI TLA. Typically, we are tolerable to the changes to the management interfaces on the basis that applications do not manage the system, this is delegated to the management utilities normally from the base. So both examples with ipfw and carp would fit there. But, in the global landscape we have exemplary actions were people go to quite the efforts to keep things running. I mean at least both Windows and Linux. Last time I looked, Linux care to provide drm1-compatible ioctls which allows to run arbitrary old X server on newest kernels, assuming old X servers have the drivers for the hardware. This is insane, isn't it? On the similar scale, I am aware that Windows provides the bug compatibility features in the memory allocators, again to provide perfect ABI. Clearly FreeBSD has not enough work power to be on par, but why voluntaristically break things when it costs nothing to not break them? > > 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? Well, I think GENERIC is sometimes trimmed from COMPAT_ options. Similarly, the most spicy options are not added there. E.g. COMPAT43 or a.out activator together with the lcall $7,$0 syscall interface on amd64 (but adding them allows you do to buildworld in 1.1.x jail, nice?).help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?aUf2lFzR2VbaBwqd>