Automagic bridged networking with QEMU (tap)

[martinko]

Juergen Lock wrote:
> 
>  I like the idea, but found it needs a patch to qemu or otherwise a
> KASSERT gets triggered in the tap driver (sys/net/if_tap.c:tap_destroy(),
> causing a `tapX flags is out of sync' panic if the driver is built with
> INVARIANTS) because the tap interface gets destroyed before its /dev/tap
> fd is closed:
> 
> Index: qemu/net.c
> @@ -961,11 +961,12 @@
>  {
>      TAPState *s = vc->opaque;
>  
> -    if (s->down_script[0])
> -        launch_script(s->down_script, s->down_script_arg, s->fd);
> -
>      qemu_set_fd_handler(s->fd, NULL, NULL, NULL);
>      close(s->fd);
> +
> +    if (s->down_script[0])
> +        launch_script(s->down_script, s->down_script_arg, -1);
> +
>      qemu_free(s);
>  }
>  
>  I guess the driver could handle this condition more gracefully, but
> until then...  Oh and I also found the ifdown script doesn't get called
> in all cases, like when you quit qemu via the monitor.
> 
>  Btw, can someone test this on 6.3?  I'm wondering if we could ship
> these ifup/down scripts in the qemu port(s) by default, maybe with an
> rcvar added to enable them or something like that.  (and the other
> config instructions in the pkg-message file.)  If you don't mind... :)

Hallo Juergen,

I certainly don't mind shipping those scripts of mine.  Thank you for 
the patch, I wasn't aware of any panics, though I was thinking along the 
lines if it's ok to destroy a tap while Qemu apparently has got it open.

I don't use Qemu monitor but I quess quitting from there should behave 
the same way and it's a Qemu bug if the scripts are not called, imho.

Regards and thank you for all the work on Qemu port.

Martin