From nobody Fri Dec 19 20:51:00 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 4dY07G6VV8z6KFlK; Fri, 19 Dec 2025 20:51:06 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dY07G46nLz3Mkw; Fri, 19 Dec 2025 20:51:06 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1766177466; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=EE1HlVvQ0rsVybdQEXcvH2MXisI3ldoSbjo+vDjTW1M=; b=kOebvP9XQdvkYBbfuBygHXGIneo71GCSj3ZugUdeVI0/hK+Uimy+Ig0JS9Gc0KOtpn663s /4NRIbSYkZtvPLyIGaS381L6EgC+Gjuq8s3QxT2MnIm1V+rWb/2OPHSy5+owND2bUFn9ni oTgR32B69+PDXXh+iHYJKngkhgYW4iBYpPvim8xOeqJP+BISBWtXRc+rlIERS9QP3uZVKN HerzyQu2R6tGm+WGR10PY5plZLS3PF3J3DtewTAbaOGDC92TBHmTZlsflqpsJEy08pEVRE 0leydAhqA9jSOoPbS9iDEWmF5h+/6jLmwWlnnxPguBDMgzabgU0LoHojjAaNdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1766177466; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=EE1HlVvQ0rsVybdQEXcvH2MXisI3ldoSbjo+vDjTW1M=; b=ye9b+OWaqv++znlQIFXVVY4fUTmmKeq3hRlUo2p6P+I5f/b0fnqNd/bWvORQKJGk5k8EQ0 nuh0kEjVpXkzwiNGn+c4MMXPngiySUTKIFrIskcCIXQlV7ZIGOBmDSQA0h7R310+tCM/Qa oHmkd8oCkCnuxX4sfFkxdj2efu9wZPBLCsGlWOCBSG3e6p70lbIs1kecOJ0loSD2Bu+R2N f6GS2yPkoWrOeLqmb6TTIO9M3tKrZLLc2MLRyLkrrD/9cm2IhuMFu4OjyjRedahgbVh3bA yWsnQzcQnGvtXkXnGkbKv144cOc/oBuZqynjkO6C8jOXHECIWY732Eue5+47gg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1766177466; a=rsa-sha256; cv=none; b=BqnHORo7VuKj5j8zqaPM8BM7xyvFo3zUMiSVHAGYjH1UOKT8AUwVTKw/vCgEaaezNSqSZF 8co1ehm/SGVu2oJ5jZajWbJ9wVKFK1FSurulunNoRHl3K1nH1AlUyHL7u7TiE+tj+SU9/1 vg7ecsTJ4bD3JSrHvJQloCdTk5ay2hS27+di1hJnlf3WYLaGdR1pHmV3SQjaA2vGXnjH/V xhiIbn6MDUQJ7vRlkoMGnpQFGBvJwpYqwe4Y22TFcQlsxQVJBcHvxSMGtfnF7oueASvRRp El3DsKSGg4Ko5/9Rcm51nYFByx9GbyqAAJjs6fg1s0w9SLCn0v123DsX+tAtvA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from cell.glebi.us (glebi.us [162.251.186.162]) (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) (Authenticated sender: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dY07F5c74ztx2; Fri, 19 Dec 2025 20:51:05 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Fri, 19 Dec 2025 12:51:00 -0800 From: Gleb Smirnoff To: Konstantin Belousov 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: 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. 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"? If you think that my deprecation was too abrupt, can you please suggest your deprecation plan? -- Gleb Smirnoff