On Fri, 12 Dec 2025 13:30:32 +1100
David Gibson
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. 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