en Copyright 2015 Java http://172.16.0.5:8080/history/freebsd-14.2/sys/modules/if_tuntap/Makefile#031beb4e sys: Remove $FreeBSD$: one-line sh patternRemove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/ List of files: /freebsd-14.2/sys/modules/if_tuntap/Makefile Wed, 16 Aug 2023 17:54:58 +0000 Warner Losh <imp@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-14.2/sys/modules/if_tuntap/Makefile#bc9ea1ce if_tuntap: remove if_{tun,tap}.ko -> if_tuntap.ko linksThese drivers have been merged into a single if_tuntap in 13.0. Thecompatibility links existed only for the interim and will be MFC'd alongwith the if_tuntap merge shortly.MFC after: never List of files: /freebsd-14.2/sys/modules/if_tuntap/Makefile Mon, 21 Oct 2019 20:28:38 +0000 Kyle Evans <kevans@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-14.2/sys/modules/if_tuntap/Makefile#251a32b5 tun/tap: merge and rename to `tuntap`tun(4) and tap(4) share the same general management interface and have a lotin common. Bugs exist in tap(4) that have been fixed in tun(4), andvice-versa. Let's reduce the maintenance requirements by merging themtogether and using flags to differentiate between the three interface types(tun, tap, vmnet).This fixes a couple of tap(4)/vmnet(4) issues right out of the gate:- tap devices may no longer be destroyed while they're open [0]- VIMAGE issues already addressed in tun by kp[0] emaste had removed an easy-panic-button in r240938 due to devdrnblocking. A naive glance over this leads me to believe that this isn't quitecomplete -- destroy_devl will only block while executing d_* functions, butdoesn't block the device from being destroyed while a process has it open.The latter is the intent of the condvar in tun, so this is "fixed" (forcertain definitions of the word -- it wasn't really broken in tap, it justwasn't quite ideal).ifconfig(8) also grew the ability to map an interface name to a kld, sothat `ifconfig {tun,tap}0` can continue to autoload the correct module, and`ifconfig vmnet0 create` will now autoload the correct module. This is alow overhead addition.(MFC commentary)This may get MFC'd if many bugs in tun(4)/tap(4) are discovered after this,and how critical they are. Changes after this are likely easily MFC'dwithout taking this merge, but the merge will be easier.I have no plans to do this MFC as of now.Reviewed by: bcr (manpages), tuexen (testing, syzkaller/packetdrill)Input also from: melifaroRelnotes: yesDifferential Revision: https://reviews.freebsd.org/D20044 List of files: /freebsd-14.2/sys/modules/if_tuntap/Makefile Wed, 08 May 2019 02:32:11 +0000 Kyle Evans <kevans@FreeBSD.org>