From owner-freebsd-emulation@FreeBSD.ORG Tue Aug 25 18:00:34 2009 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D36B106568B; Tue, 25 Aug 2009 18:00:34 +0000 (UTC) (envelope-from fli@shapeshifter.se) Received: from mx1.h3q.net (mx1.h3q.net [IPv6:2001:16d8:ffe5:1::f1]) by mx1.freebsd.org (Postfix) with ESMTP id 22C888FC14; Tue, 25 Aug 2009 18:00:33 +0000 (UTC) Received: from smtp-auth.h3q.net (smtp-auth.h3q.net [127.0.0.1]) (Authenticated sender: hidden) by mx1.h3q.net (Postfix) with ESMTPSA id 9B11B33CB7 ; Tue, 25 Aug 2009 20:00:32 +0200 (CEST) Message-ID: <4A9426BD.1050503@shapeshifter.se> Date: Tue, 25 Aug 2009 20:00:29 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 2.0.0.22 (X11/20090801) MIME-Version: 1.0 To: Robert Watson References: <4A8EB3D2.7010109@shapeshifter.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-emulation@freebsd.org Subject: Re: VirtualBox bridged adapter (vboxnetflt) X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 18:00:34 -0000 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