From owner-freebsd-net@FreeBSD.ORG Mon Jul 2 01:30:21 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8D5816A421; Mon, 2 Jul 2007 01:30:21 +0000 (UTC) (envelope-from zec@tel.fer.hr) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.freebsd.org (Postfix) with ESMTP id 4048313C43E; Mon, 2 Jul 2007 01:30:21 +0000 (UTC) (envelope-from zec@tel.fer.hr) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id 04B369B64D; Mon, 2 Jul 2007 03:09:36 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from tpx32.icir.org (zec2.tel.fer.hr [161.53.19.79]) by xaqua.tel.fer.hr (Postfix) with ESMTP id 705179B646; Mon, 2 Jul 2007 03:09:34 +0200 (CEST) From: Marko Zec To: freebsd-net@freebsd.org Date: Mon, 2 Jul 2007 03:09:32 +0200 User-Agent: KMail/1.9.1 References: <467C1E3C.1020203@elischer.org> <467C5EEC.1000208@icir.org> <467C6B79.4080304@elischer.org> In-Reply-To: <467C6B79.4080304@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707020309.33179.zec@tel.fer.hr> Cc: ambrisko@freebsd.org, andre@freebsd.org, "Bruce M. Simpson" , releng@freebsd.org, Julian Elischer Subject: Re: Vimage virtual networking and 7.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2007 01:30:21 -0000 On Saturday 23 June 2007 02:38, Julian Elischer wrote: > Bruce M. Simpson wrote: > > Julian Elischer wrote: > >> In the future I am hoping to be able to use vimage in our > >> products. They are based at the moment on 6.1, but I can see in a > >> year they will be based on 7.x. > >> > >> Patches for 7.0 and vimage are currently available in perforce. > >> What I would like to see is if there are any parts of that patch > >> that would allow us to make adding of vimage to 7.1 an easier > >> task. > >> > >> For example, Anything that would prevent vimage from > >> needing an API change that would prevent it from being added > >> later. > > > > My concern is that this may have already happened. I've been trying > > to do my bit as the years edge on to clean up the networking stack > > and fix bugs. One of my concerns is that the vimage change, which > > attempts to take network stack globals and wrap them into one big > > structure, may intrude on this or be subject to bitrot due to other > > development. > > > >> I am quite disappointed that despite Marko's best efforts, we miss > >> the 7.0 > >> release but if it can be made nonintrusive enough I'd really like > >> to see if it can get in 7.1. > > > > I appreciate all the hard work Marko has done on this, though I > > wonder if even 7.1 is ambitious. > > > >> Personally, if I were "god" I'd put it in now because it can be > >> compiled out. > >> and it wouldn't be compiled by default.Maybe only just bits of > >> it.. for sure I want the ability to have many routing tables. > >> and I'm not thrilled about the requirement to have my own patch > >> sets for this and thus not allowing others to use this feature. > > > > I think there are deeper issues in the network stack overall which > > need to be addressed, such as our lack of support for multipathing, > > scoped addresses, and all the tidyups which need to happen in > > struct ifnet to deal with this. > > > > My concern is that vimage may be a very intrusive change indeed > > where these matters are concerned, unless the vimage patches are > > being kept up-to-date and regression tested as issues are resolved > > and new features added. > > This is axectly why I think they should go in now. > Remembering that they compile out to non changes.. > > Marko will I believe continue to keep up with -current as changes are > made there. however it would be easier if they were in the tree so > that people MAKING the new changes just took it into account when > they did it. My plan is to deliver hopefully a production-grade snap-in replacement kernel with virtualized networking for 7.0-RELEASE when it ships, and in parallel continue to sync the work with -CURRENT until it becomes feasible for merging, or until it becomes apparent that it will never get merged... Julian you're right it would be much simpler not to have to track two separate branches in the future, but the blame for missing the window for 7.0 is entirely on me being distracted from the project for quite a while. And honestly the virtualization changes are not yet ready for prime time at this moment. Marko > Similarly it will be a lot harder to backport to 7.x unless we keep a > a separate 7.x + vimage branch in p4 however that means that marko > will need to do everything twice. > > > BMS > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to > > "freebsd-net-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org"