From owner-freebsd-arch@FreeBSD.ORG Sat Aug 16 13:05:33 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E66D106566B; Sat, 16 Aug 2008 13:05:33 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5879E8FC08; Sat, 16 Aug 2008 13:05:33 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id CFFAA1589C2; Sat, 16 Aug 2008 09:05:31 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Sat, 16 Aug 2008 09:05:31 -0400 X-Sasl-enc: B5VDFt4auON9J5ARbzCZag+MydjGxuxeqPjkhBYqSYTx 1218891931 Received: from [192.168.1.235] (76-191-150-176.dsl.dynamic.sonic.net [76.191.150.176]) by mail.messagingengine.com (Postfix) with ESMTPSA id CAB4722968; Sat, 16 Aug 2008 09:05:30 -0400 (EDT) Message-ID: <48A6D104.2010704@freebsd.org> Date: Sat, 16 Aug 2008 06:07:16 -0700 From: Darren Reed User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Julian Elischer References: <1218809394.10612.1268815905@webmail.messagingengine.com> <48A5CBEE.6090603@elischer.org> In-Reply-To: <48A5CBEE.6090603@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, Robert Watson , current@FreeBSD.org Subject: Re: Advanced warning: virtualization work will be afoot X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2008 13:05:33 -0000 Julian Elischer wrote: > Darren Reed wrote: >> Robert, >> >> Do you have any more information about what the details of >> this virtualization work will be? e.g. will it be similar >> to what Solaris has with zones? >> >> The reason that I ask is that I've just finished getting >> the ipfilter code (non-Sun code) converted to being zone >> aware. What does that mean? Lots of global variables are >> gone, replaced by soft-context structures that are allocated >> and free'd when zones come alive/die. For BSD, while all >> of the code paths are the same, I'm currently only using >> a single soft context and just pass around a pointer to >> it. >> >> If you're going to be doing similar work for FreeBSD, I >> will try and get this into the tree sooner, rather than >> later, so that there's one less component that you need >> to worry about. >> >> Cheers, >> Darren > > > > look at the following document: > > http://perforce.freebsd.org/fileLogView.cgi?FSPC=//depot/projects/vimage/porting_to_vimage.txt > > > sorry if that wraps > > there are patches at: > > also look at the patches in the ipfilter files in that branch. So the only changes I could see are V_* things for inet global variables that ipfilter abuses. Was there something else that I'm missing? > If you are doingthe work for zones then that will be applicable. It's now close to complete. There are 3 "layers" of data structure initilisation to get it running: - load (initialise all of the globals) - create (create the soft context structure) - init (build tables, register callbacks to get packets, etc.) > ... > the aggregate diff can be found at: > > http://www.freebsd.org/~julian/vimage.diff. > > If you want to handle ipfilter yourself then we'd be happy to let you > do it. At the moment, those diffs for IPFIlter only have some V_* changes for dealing with the global inet variables that it abuses. Is there more hidden somewhere? To get a proper idea of the changes I've been working on you should download this guy: http://coombs.anu.edu.au/~avalon/ip_fil5.0.3.tar.gz Nearly all of the global variables are gone, with bits and pieces hanging off ipf_*_softc_t structures now. So far as ipfilter/ipfw/pf go, for them to be meaningfully virtualised, the pfil code that currently supports them needs to be enhanced further such that they can "listen" for the creation of vimages, etc...that is if people want to delegate (partial) control of such to vimages. Darren