src/sys/modules/if_tuntap, branch stable/13FreeBSD source treehttps://cgit-dev.freebsd.org/src/atom?h=stable%2F132023-08-23T17:43:27Zsys: Remove $FreeBSD$: one-line sh pattern2023-08-23T17:43:27ZWarner Loshimp@FreeBSD.org2023-08-22T01:31:56Zurn:sha1:5510f79042fbd543de55807d0da7f8a2b8be2f89
Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
Similar commit in current:
(cherry picked from commit 031beb4e239b)
if_tuntap: remove if_{tun,tap}.ko -> if_tuntap.ko links2019-10-21T20:28:38ZKyle Evanskevans@FreeBSD.org2019-10-21T20:28:38Zurn:sha1:bc9ea1ceb8b23b22c6599d4637137df9c2091b9b
These drivers have been merged into a single if_tuntap in 13.0. The
compatibility links existed only for the interim and will be MFC'd along
with the if_tuntap merge shortly.
MFC after: never
tun/tap: merge and rename to `tuntap`2019-05-08T02:32:11ZKyle Evanskevans@FreeBSD.org2019-05-08T02:32:11Zurn:sha1:251a32b5b2babf50556669b192f5820a61f6d900
tun(4) and tap(4) share the same general management interface and have a lot
in common. Bugs exist in tap(4) that have been fixed in tun(4), and
vice-versa. Let's reduce the maintenance requirements by merging them
together 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 devdrn
blocking. A naive glance over this leads me to believe that this isn't quite
complete -- destroy_devl will only block while executing d_* functions, but
doesn'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" (for
certain definitions of the word -- it wasn't really broken in tap, it just
wasn't quite ideal).
ifconfig(8) also grew the ability to map an interface name to a kld, so
that `ifconfig {tun,tap}0` can continue to autoload the correct module, and
`ifconfig vmnet0 create` will now autoload the correct module. This is a
low 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'd
without 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: melifaro
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D20044