From nobody Fri Dec 19 20:37:57 2025 X-Original-To: dev-commits-src-main@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 4dXzrK3SYfz6KDg1; Fri, 19 Dec 2025 20:38:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4dXzrJ5qbHz3KX0; Fri, 19 Dec 2025 20:38:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 5BJKbvIo093268; Fri, 19 Dec 2025 22:38:00 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5BJKbvIo093268 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5BJKbvoI093267; Fri, 19 Dec 2025 22:37:57 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 19 Dec 2025 22:37:57 +0200 From: Konstantin Belousov To: Gleb Smirnoff 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: <693a275a.2e7b3.1858af56@gitrepo.freebsd.org> List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.2 X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on tom.home X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dXzrJ5qbHz3KX0 On Fri, Dec 19, 2025 at 12:18:04PM -0800, Gleb Smirnoff wrote: > On Fri, Dec 19, 2025 at 09:57:17PM +0200, Konstantin Belousov wrote: > K> We are discussing different things altogether. > K> > K> I am saying that you are breaking binary compatibility, and asking why. > K> I do not see a reason. > K> > K> It has no relation to the fact that there are other ways to get the same > K> behaviour from the system. The removal of that three lines breaks existing > K> binaries. Also it does not matter that e.g. newer versions of some apps > K> do not use that feature (feature as in binary interface, not a system > K> behaviour). The existing binaries must continue to work. > > We already have had this argument before for a different kind of issue - > POLLINIGNEOF. The existence of such binaries is like existence the the God. > You can't prove they exist. I can't prove they do not exist. You advocate for > the compat shim to exist forever. I advocate to limit it existence to some > countable number of years. > > For this particular case all open source software had been addressed. There > are no known shareware binaries in the wild that used AF_INET/IPPROTO_DIVERT. I do not understand this statement. It was demonstrated in this thread that python had it. > Those hypothethical binaries that we can't prove/refute existence of in some > corporate environments would print a warning on 14.x and on 15.x providing a > time to their owners to recompile. If we speculate that somewhere in the > universe exists a corporate body that uses AF_INET/IPPROTO_DIVERT tuple in > their internal software and have lost its source code, they have a solution. > The solution is a tiny preloaded library that would intercept socket(2). Of > course you may say that somewhere in the world exists a closed ecosystem that > uses AF_INET/IPPROTO_DIVERT in a binary AND the sources for the binary were > lost AND the binary is statically compiled. If you decide to go that deep into > the rabbit hole, I would reply that owners of such a binary should bit hack it > to use the correct tuple before call to socket(2). No. You abruptly break binary compatibility and claim that this is fine. It is not.