#
bc9ea1ce |
| 21-Oct-2019 |
Kyle Evans <kevans@FreeBSD.org> |
if_tuntap: remove if_{tun,tap}.ko -> if_tuntap.ko links
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 w
if_tuntap: remove if_{tun,tap}.ko -> if_tuntap.ko links
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
show more ...
|
#
251a32b5 |
| 08-May-2019 |
Kyle Evans <kevans@FreeBSD.org> |
tun/tap: merge and rename to `tuntap`
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
tun/tap: merge and rename to `tuntap`
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
show more ...
|