Date: Tue, 25 Aug 2009 20:00:29 +0200 From: Fredrik Lindberg <fli@shapeshifter.se> To: Robert Watson <rwatson@FreeBSD.org> Cc: freebsd-emulation@freebsd.org Subject: Re: VirtualBox bridged adapter (vboxnetflt) Message-ID: <4A9426BD.1050503@shapeshifter.se> In-Reply-To: <alpine.BSF.2.00.0908251732270.61512@fledge.watson.org> References: <4A8EB3D2.7010109@shapeshifter.se> <alpine.BSF.2.00.0908251732270.61512@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote:
>
> On Fri, 21 Aug 2009, Fredrik Lindberg wrote:
>
>> I've started working on the missing bits of the FreeBSD network
>> implementation in VirtualBox.
>>
>> I now have a working vboxnetflt.ko driver that allows automatic
>> bridged networking in VirtualBox (probably what most people want).
>> This allows guests to automatically bridge with your existing network
>> adapter providing seamless network access.
>>
>> Work on host-only adapter mode is in progress (this should not be
>> confused with host-interface in previous vbox 2.x releases).
>
> Hi Fredrik:
>
> The technical approach you've taken here is a bit unusual and
> potentially quite fragile -- replacing the method pointers on struct
> ifnet's maintained by other drivers and "borrowing" spare fields is
> likely going to prove problematic in the future (and, in fact, already).
>
> It looks like a lot of what the driver is trying to accomplish can
> already be done entirely from userspace using bpf(4): taking a tee of
> incoming frames arriving at the NIC, perhaps selecting down to ones to
> specific ethernet addresses, taking the card into and out of promiscuous
> mode, and injecting frames into the output path, are exactly what BPF is
> designed to support. I was wondering if you'd looked at this approach
> as an alternative to a custom kernel driver?
>
> Robert
>
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 ?
Fredrik Lindberg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A9426BD.1050503>