Re: [PATCH] udp: Rename udp_buf_sock_to_tap() and udp_vu_sock_to_tap()

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:

...

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 interface, not the tap interface. Rename it to udp_sock_to_vu() to accurately reflect its destination.

The function udp_buf_sock_to_tap() includes a "buf_" prefix that is now redundant. Since the functions can be distinguished by their destination (to_tap vs. to_vu), drop the prefix and rename it to udp_sock_to_tap().

No functional change.

Signed-off-by: Laurent Vivier

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.

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.

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 from 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. -- 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