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

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(a)redhat.com> wrote:
 
  From: Laurent Vivier <laurent(a)vivier.eu>
 
 Signed-off-by: Laurent Vivier <laurent(a)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