Date: Fri, 28 Aug 2009 22:25:26 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Fredrik Lindberg <fli@shapeshifter.se> Cc: freebsd-emulation@freebsd.org Subject: Re: VirtualBox bridged adapter (vboxnetflt) Message-ID: <alpine.BSF.2.00.0908282223170.68412@fledge.watson.org> In-Reply-To: <4A9426BD.1050503@shapeshifter.se> References: <4A8EB3D2.7010109@shapeshifter.se> <alpine.BSF.2.00.0908251732270.61512@fledge.watson.org> <4A9426BD.1050503@shapeshifter.se>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 25 Aug 2009, Fredrik Lindberg wrote:
> That's why I ended my mail by saying it's "hackish" (which usually mean
> fragile) :)
>
> vboxnetflt is a driver that exists for all operating systems capable of
> running in virtualbox host mode. It consists of both operating system
> independent code and operating system dependent code. This together forms a
> kernel module (on all host OS) which in turn depend on symbols in the other
> kernel support driver (vboxdrv.ko).
>
> So, unless we re-write a lot of the generic code in VBox, this have to be
> done in the kernel (disclaimer, I haven't really looked on what would have
> to be changed, but it's not very attractive to start messing with their
> generic code).
>
> I've actually looked at BPF..but didn't find a clean API from the kernel
> (maybe I just don't know where to look). (Opening /dev/bpf from the kernel
> seemed just as fragile as the current approach if it's even possible).
>
> The third approach is to add vbox glue to ifnet and ether_output, but that
> is just as bad (accounting for third party software in the kernel is just
> ugly).
>
> At least Darwin seems to have a "filtering" mechanism that allows you to
> manipulate mbufs before they are sent to the interface. Linux seems to have
> a similar mechanism, but not as flexible as the one in Darwin.
>
> I was thinking along the same lines for FreeBSD. Implementing generic hooks
> in the input/output path that could be used for vbox, if_bridge, carp, etc,
> instead of the current hard coded calls in ether_{output,input}. This could
> also have the effect of removing module specific glue from struct ifnet.
> Anything worth pursuing ?
In the past, we've talked about adding PFIL hooks for interface input/output
paths, and in fact there's already a PFIL constant for it, it's just not
hooked up to anything: PFIL_TYPE_IFNET. I think it would be a useful to flesh
this out, but we'll need to decide where to place them. I think the right
spot is probably in the link layer input/output routines -
ether_{input,output} in particular, but also at other layers, such as in the
VLAN code. Not for 8.0, obviously. :-) You'll still need to use an m_tag so
you can mark traffic you've generated and ignore it when it gets picked up by
a hook, of course.
Robert N M Watson
Computer Laboratory
University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0908282223170.68412>