Remove residual blank line at start of MakefileThis is a residual of the $FreeBSD$ removal.MFC After: 3 days (though I'll just run the command on the branches)Sponsored by: Netflix
sys: Remove $FreeBSD$: one-line sh patternRemove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
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 alongw
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
show more ...
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
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