Re: TEST PLEASE: if_tun patch

On Sun, Sep 28, 2003 at 10:04:42PM -0700, Brooks Davis wrote:

> I'm not convinced this is the right direction to move in.  The problem
> is that users are beginning to expect that pseudo-interfaces be created
> with network interface cloning, but tun, tap, and vmnet aren't.  I'm

Same about ef(4) pseudo-interfaces.
Another thing is that someone may want to create vlan(4) and ef(4)
pseudo-interfaces on tap(4) interface, like this:

(1)ttyp4 [~]>ifconfig tap19
tap19: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 10.19.0.1 netmask 0xffffff00 broadcast 10.19.0.255
        inet6 fe80::2bd:69ff:fe94:13%tap19 prefixlen 64 scopeid 0x13
        ether 00:bd:69:94:00:13
(2)ttyp4 [~]>ifconfig vlan0 create
(3)ttyp4 [~]>ifconfig vlan0 vlan 123 vlandev tap0
(4)ttyp4 [~]>ifconfig vlan0
vlan0: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1496
        ether 00:bd:68:94:00:00
        vlan: 123 parent interface: tap0
(5)ttyp4 [~]>kldload if_ef
(6)ttyp4 [~]>ifconfig tap19f2
tap19f2: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        ether 00:bd:69:94:00:13

I have no idea if it works. ;)
[screenshot from 4.x, I have no 5.x at this moment]

It looks strange to have `ifconfig create' vlan interface on tap,
while tap uses different semantics and can disappear after closing it?
With ef it is even worse, pseudo-devices are created while ef is
starting, so ef module must be loaded after creating every ethernet
device.

> concerned that this destroy on last close semantic will make it harder
> to implement that.  I guess if we moved to a model where we allowed both
> methods to work, we could somehow add an extra reference when we cloned
> interfaces via "ifconfig <if> create", but I don't know the devfs side
> well enough to know if that's possible.



-- 
Paweł Małachowski