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

[Stefano Brivio <sbrivio@redhat.com>]

On Fri, 12 Dec 2025 13:30:32 +1100
David Gibson <david@gibson.dropbear.id.au> 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 <lvivier@redhat.com>  
> 
> 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.

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.

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?

-- 
Stefano