Akihiko Odaki wrote: > tun and tap implements the same vnet-related features so reuse the code. > > Signed-off-by: Akihiko Odaki <akihiko.od...@daynix.com> > --- > 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. > +obj-$(CONFIG_TAP) += tap-drv.o > +tap-drv-y := tap.o tun_vnet.o > obj-$(CONFIG_VETH) += veth.o > obj-$(CONFIG_VIRTIO_NET) += virtio_net.o > obj-$(CONFIG_VXLAN) += vxlan/
