From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=202512 header.b=W4VOZqQh; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id ED6625A0652 for ; Mon, 15 Dec 2025 03:05:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202512; t=1765764348; bh=p2N0TVoHYkNVMJruzswrrsXDXozTORJAzYKAXg2+w6g=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=W4VOZqQhfuX2z0NJ7An6EpNqk7qhOt3mzR8iujAYQ7NhyPsUxxl6KsQFi/HHiLyjQ GZ4SPzKE3K5JPc71/ax4cLXbiHDNSbw5bFkjWmgJnMTS0fmDsbCRH6KCw5O2XS1mZQ VPPYX7BCyUOfsJzCYh177iKYKZup/tBvOBZYFrCrb9p2qgV8jjpRRijHZgaBl+6k0I PQAiLm3FKl3ikwFV7Zq/5Im5YZOQApaNhNHZbXWnIx0C1+2sFfR4up4eg6ujmB3Ztq l2QyfCpOyqakyaDLZolhtnvgBij5JMEvA7zvhB3bvx4avCkSPv/frCwpSCm4lu3Q3h iAd/hb7knsAeg== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4dV3Lh5dcKz4wHW; Mon, 15 Dec 2025 13:05:48 +1100 (AEDT) Date: Mon, 15 Dec 2025 13:05:30 +1100 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH] udp: Rename udp_buf_sock_to_tap() and udp_vu_sock_to_tap() Message-ID: References: <20251211141626.301969-1-lvivier@redhat.com> <20251213025508.231f94ef@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xg511OZKLEJfMnCC" Content-Disposition: inline In-Reply-To: <20251213025508.231f94ef@elisabeth> Message-ID-Hash: UGXJQCFVR6EWZKFNTLTGL3KTTOUBAQZ6 X-Message-ID-Hash: UGXJQCFVR6EWZKFNTLTGL3KTTOUBAQZ6 X-MailFrom: dgibson@gandalf.ozlabs.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Laurent Vivier , passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --xg511OZKLEJfMnCC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 13, 2025 at 02:55:08AM +0100, Stefano Brivio wrote: > On Fri, 12 Dec 2025 13:30:32 +1100 > David Gibson wrote: >=20 > > On Thu, Dec 11, 2025 at 03:16:26PM +0100, Laurent Vivier wrote: > > > The function udp_vu_sock_to_tap() sends data to the vhost-user interf= ace, > > > not the tap interface. Rename it to udp_sock_to_vu() to accurately re= flect > > > its destination. > > >=20 > > > The function udp_buf_sock_to_tap() includes a "buf_" prefix that is n= ow > > > redundant. Since the functions can be distinguished by their destinat= ion > > > (to_tap vs. to_vu), drop the prefix and rename it to udp_sock_to_tap(= ). > > >=20 > > > No functional change. > > >=20 > > > Signed-off-by: Laurent Vivier =20 > >=20 > > Eh, I mean using "tap" to mean the guest side interface, even if it's > > not based on /dev/net/tap is pretty well established at this point. > >=20 > > I do think udp_sock_to_vu() is a better name regardless. I'm a bit > > less convinced on renaming udp_buf_sock_to_tap(). If we're trying to > > abandon the "tap means any guest interface" convention, then > > udp_sock_to_tap() is still inaccurate, since it can also send to a > > qemu socket. If we're not trying to abandon that convention then it > > suggests that the function does any forwarding to the guest, not just > > the non-vu case. >=20 > Assuming we're not trying to abandon that convention: why can't "tap" > be "anything that's not vhost-user"? We could document that at the top > of tap.c and it would still be clearer than the current situation. I mean, I guess we could. It seems weirdly arbitrary to me. > It would be still somewhat confusing that a big part of the code in > tap.c is also relevant for vhost-user, but in a number of places, > there, we call the vhost-user specific implementation and return early. Right. We could potentially rename many of the current "tap" things to, say "guestif"? Although I guess that doesn't make the distinction =66rom the splice interface clear. > I got to dislike "buf" over timing because it's more typing and doesn't > mean much other than "non-vhost-user" (vhost-user uses buffers too). > Maybe we could live happier by letting "tap" be that magic word? I don't love it, but I don't dislike it enough to complain (much) if you choose to go that way. --=20 David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson --xg511OZKLEJfMnCC Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmk/bOkACgkQzQJF27ox 2Gfx6Q//dJW+xntbotWMJUZO/1PIWg7MabLSd8KNNiPv9kl+owUaOETEetpT4c06 oJ8Qn/Bx4WpcKllnhldiye3er0zh7xKYjL7fAQA2sQvlbpOnMcF7OOxLOojrGXuG j+cJuu7D7ParuSb5IpNLcwjq4X+7A+QeE9RLbHzerIRnAchJiy/iiT/YaMJeqxQQ WEDfC9j6VnP5OaKSS4jv/foLdffw2CHKo9m8CKGaBzxVWGUQU9orcDiYRjm7q9ry E9DG6UpEOhxiX6tLDLk6+dca+7VAJXsU5RKMDdkqvZC/8yGiaHfxeo0ZQzDWsLyq 7EE04wFsWxl4h5IdYuVcqV5PklUU4bVGFUbGxs/lDzCJ4NDB/ieN2c3JxXMs4Wed xMvDZ/N5WbOFKPKcBebkNnWi55ZSn72Cey1pgK1U91JlmoT1CwcW8UkdXo6XZBvj GFcuJejxG5rUCOp/5vEVCmMI8zUebw+3er+5Q9M4CzUZilxLlcyQe1zYyPSsQ2yB 90VJriShIcu97jgb7+3ys3w9Yds9g+mrB+aCV8VOVQxUD+EDQLDjRUKuN5wWsMaE FZDntvizAh/rppFiV76X3Zs1H9aWgCo8hYd+RO0ntXH+HajtrsFwaaGJfKMs//Uc OAaTvc3nioP9ckeZi1XGF0qJkJ8lQcwldCXMlqoVKTbj3x4z5E0= =gVgd -----END PGP SIGNATURE----- --xg511OZKLEJfMnCC--