From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=W1rr0Adu; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id 504C85A0653 for ; Sat, 13 Dec 2025 02:55:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1765590913; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5ItI8Aql+k01+m3lSDg1DH/PSG0qqTwdaeMaarQoPto=; b=W1rr0AduxJXQlx3PO7ufHoe2hoNa/Hj0wccgO++72oDiay1xgL10aPDM4QcO8CRh/nbfED U60DmILUfn0uQO6N4Mchr+BcsyRPnIjfYZaeXQvQmfiy9nMVqYNKCFFjIj2nh+PRFBjtDR YteXRExYaUeufI/4AqNR0jQecjkDN10= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-199-RQbJ-0hAMsmT4aTqgVh8nw-1; Fri, 12 Dec 2025 20:55:11 -0500 X-MC-Unique: RQbJ-0hAMsmT4aTqgVh8nw-1 X-Mimecast-MFC-AGG-ID: RQbJ-0hAMsmT4aTqgVh8nw_1765590910 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-477a0ddd1d4so10273045e9.0 for ; Fri, 12 Dec 2025 17:55:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765590910; x=1766195710; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=5ItI8Aql+k01+m3lSDg1DH/PSG0qqTwdaeMaarQoPto=; b=ILspn35VsTuGvgq5reAQ+L1oRjfxUUmRQ3IBnsmgvLAdT5fzZy5MaSrvEhZWDR6acX 1A+hBBBRkvUyd2eJWmZDgJOIIrhA16AUz2zmFrFk3tl1rnBcS8IV2fgRbNeBd/lKnCgq Ta5tWG4s3AJch7KMKZPMKVPQPstlfMYr5zl8Okqax5FCBq2n2MiSo7Jlmkmq3ed8Q2Q4 c095ieH1OM3W5+S0PybNB9YOf4n1x5SVJJSwfyOhtX4WpKDWTa+NnWdNIWbGKsfLwJiK dZWcm5gSmjSNxWJPYhQ+ypJvLqrQMLr6X3fOBx6csoUS3XQpa3lWSEH6fd3Vq9H88Xip E9Nw== X-Forwarded-Encrypted: i=1; AJvYcCUx4bQ6JzubXeLd6zgRWRLDdBR2Gf5FyhXsxbYXpIygYnve0wAB5mbAVN3DE5eG98bhLe4g2edzGFo=@passt.top X-Gm-Message-State: AOJu0YwZCnp1MoD2qL+DOEpQd0BcEjO4AXYxPhczvq3TeZvXs9PpL4Dh Iz9I4jTncDxnro65+lM8aVbYtTkjXnJy3t/2qeB3Zi/DGgR90JAiRI+lbck4QaLE6KlxzAVEpF1 mwhBW81tEK/lsjipoPK6N6GCFVf8+lFulcO8Otv5FbTnQUkJXEkZRbQ== X-Gm-Gg: AY/fxX5egkEVUWDEQt13Wuk2jOempNnFtmjkwVgKqeDVezx39ky4mFrgcoKk0op9uoS Ru9FK+elMwRrsfe5o0RyFDKhsHDntyH1/Zc9pvEkEYEidMSoyBf/HGVISTx2bGYvwp0X8d0GIDN ACNNgjewIAeVxGyoSCK8Om+0Xb+pDQIKNMhLBtnEnggNOAXuPiY9/Lqb/aje6uo+9BcEvMerx8T LsyS05xmHss0YtnfKri0biDzSAfaJj5QYWtrM2VuLaQ/XaDDcpo9prr9WNlYxMbz/6rTbopVc0I xx++uHrcJsUiAGETeBoXr7puTgV2tP5jFPHqvcdGVElyT6GIvV5BA6VS/qAxpBYo1yUl8DSEJTe vIoKqNfcSfUO6QVfbeVR3mo9STratw1Q8HU37wg== X-Received: by 2002:a05:600c:474d:b0:477:7b72:bf9a with SMTP id 5b1f17b1804b1-47a8f90d14fmr39612315e9.28.1765590910338; Fri, 12 Dec 2025 17:55:10 -0800 (PST) X-Google-Smtp-Source: AGHT+IFHZnL5hwlyKMrw87C0DbM4DYWiBbHH+TfmEnHmh8pW6sNWu3t2cuq26rXlCFmZoDewsdaCdQ== X-Received: by 2002:a05:600c:474d:b0:477:7b72:bf9a with SMTP id 5b1f17b1804b1-47a8f90d14fmr39612155e9.28.1765590909921; Fri, 12 Dec 2025 17:55:09 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-42fa8b8a9b9sm15915732f8f.35.2025.12.12.17.55.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Dec 2025 17:55:09 -0800 (PST) Date: Sat, 13 Dec 2025 02:55:08 +0100 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH] udp: Rename udp_buf_sock_to_tap() and udp_vu_sock_to_tap() Message-ID: <20251213025508.231f94ef@elisabeth> In-Reply-To: References: <20251211141626.301969-1-lvivier@redhat.com> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: nCIiog8xhJN3naH6osSwrj329d_yWy3zMAxdl8WsgM4_1765590910 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: DCKJCDW2ZPBHSYGGQM7FFLHXZ4JUXBIR X-Message-ID-Hash: DCKJCDW2ZPBHSYGGQM7FFLHXZ4JUXBIR X-MailFrom: sbrivio@redhat.com 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: 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. 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