Re: [PATCH 13/24] tap: export pool_flush()/tapX_handler()/packet_add()

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]

On Mon, Feb 12, 2024 at 12:15:30AM +0100, Stefano Brivio wrote:
> On Fri,  2 Feb 2024 15:11:40 +0100
> Laurent Vivier <lvivier@redhat.com> wrote:
> 
> > From: Laurent Vivier <laurent@vivier.eu>
> > 
> > Signed-off-by: Laurent Vivier <laurent@vivier.eu>
> > ---
> >  tap.c | 98 +++++++++++++++++++++++++++++------------------------------
> >  tap.h |  7 +++++
> >  2 files changed, 56 insertions(+), 49 deletions(-)
> 
> I'm assuming that you need this patch to recycle those bits of "tap"
> functions for usage in vhost-user code... which shows they actually
> have little to do with tun/tap interfaces.
> 
> But sure, we already have there stuff to deal with UNIX domain sockets,
> so "tap" is already somewhat inconsistent.
> 
> If use "tap" for a (long) moment to denote "anything guest/container
> facing", then:

We're definitely doing that at present.  I am wondering with adding
this third "tap" option that's even further from tuntap whether we
should rethink that naming convention.  I was contemplating something
along the lines of "l2if" emphasizing that the thing in common is that
it's a transport operating at L2 level, unlike the "sock" side
operating at l4.

-- 
David Gibson			| 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]