On Mon, Jan 20, 2025 at 1:37 AM Jason Wang <jasowang@xxxxxxxxxx> wrote: > > On Fri, Jan 17, 2025 at 6:35 PM Akihiko Odaki <akihiko.odaki@xxxxxxxxxx> wrote: > > > > On 2025/01/17 18:23, Willem de Bruijn wrote: > > > Akihiko Odaki wrote: > > >> tun and tap implements the same vnet-related features so reuse the code. > > >> > > >> Signed-off-by: Akihiko Odaki <akihiko.odaki@xxxxxxxxxx> > > >> --- > > >> drivers/net/Kconfig | 1 + > > >> drivers/net/Makefile | 6 +- > > >> drivers/net/tap.c | 152 +++++-------------------------------------------- > > >> drivers/net/tun_vnet.c | 5 ++ > > >> 4 files changed, 24 insertions(+), 140 deletions(-) > > >> > > >> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig > > >> index 1fd5acdc73c6..c420418473fc 100644 > > >> --- a/drivers/net/Kconfig > > >> +++ b/drivers/net/Kconfig > > >> @@ -395,6 +395,7 @@ config TUN > > >> tristate "Universal TUN/TAP device driver support" > > >> depends on INET > > >> select CRC32 > > >> + select TAP > > >> help > > >> TUN/TAP provides packet reception and transmission for user space > > >> programs. It can be viewed as a simple Point-to-Point or Ethernet > > >> diff --git a/drivers/net/Makefile b/drivers/net/Makefile > > >> index bb8eb3053772..2275309a97ee 100644 > > >> --- a/drivers/net/Makefile > > >> +++ b/drivers/net/Makefile > > >> @@ -29,9 +29,9 @@ obj-y += mdio/ > > >> obj-y += pcs/ > > >> obj-$(CONFIG_RIONET) += rionet.o > > >> obj-$(CONFIG_NET_TEAM) += team/ > > >> -obj-$(CONFIG_TUN) += tun-drv.o > > >> -tun-drv-y := tun.o tun_vnet.o > > >> -obj-$(CONFIG_TAP) += tap.o > > >> +obj-$(CONFIG_TUN) += tun.o > > > > > > Is reversing the previous changes to tun.ko intentional? > > > > > > Perhaps the previous approach with a new CONFIG_TUN_VNET is preferable > > > over this. In particular over making TUN select TAP, a new dependency. > > > > Jason, you also commented about CONFIG_TUN_VNET for the previous > > version. Do you prefer the old approach, or the new one? (Or if you have > > another idea, please tell me.) > > Ideally, if we can make TUN select TAP that would be better. But there > are some subtle differences in the multi queue implementation. We will > end up with some useless code for TUN unless we can unify the multi > queue logic. It might not be worth it to change the TUN's multi queue > logic so having a new file seems to be better. +1 on deduplicating further. But this series is complex enough. Let's not expand that. The latest approach with a separate .o file may have some performance cost by converting likely inlined code into real function calls. Another option is to move it all into tun_vnet.h. That also resolves the Makefile issues.
