From owner-freebsd-virtualization@FreeBSD.ORG Sun Aug 17 08:24:09 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD8C6106566B for ; Sun, 17 Aug 2008 08:24:09 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outE.internet-mail-service.net (oute.internet-mail-service.net [216.240.47.228]) by mx1.freebsd.org (Postfix) with ESMTP id 9E4698FC1A for ; Sun, 17 Aug 2008 08:24:09 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id B0E5A2382; Sun, 17 Aug 2008 01:24:09 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id A3B452D606F; Sun, 17 Aug 2008 01:24:08 -0700 (PDT) Message-ID: <48A7E024.3040705@elischer.org> Date: Sun, 17 Aug 2008 01:24:04 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Robert Watson , Marko Zec , freebsd-virtualization@freebsd.org, Alan Cox Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: next moves X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2008 08:24:09 -0000 My thoughts.. once commit2 is committed and effectively becomes -current, then commit3 and commit1 could be done, which would reduce the diff size more it: 1/ adds Marco's real include files and the real final definitions of V_ vars. 2/ adds a bunch of the final INIT_VNET_XXX macros in place to further reduce the size of the binaries 3/ introduces (but does not yet use) the structures that hold the globals after this we should STILL see no real binary change. If we could get the same horsepower on commit3 that we have seen on commit2 then I see no reason it would not be in a committable state in a few days.. the next step after that would be to do the vimage-commit branch, which after the commit3 branch was added would be a small additional step. It adds a few more of the macros but is aimed at pure diff reduction it may follow just a day or so after commit3. It's an incremental change, but is derived from the vimage branch rather than from the commit2 (mechanical) branch, and basically just acts as a shim in diff to get us a bit closer to where we are going. Once those branches have been committed I would suggest a step where turnign on VIMAGE actually doesn't enable vimage entirely, but simply enables global versions of the structures mentionned above. This would be the step that Brook was looking for. constructors woudl be used. Destructors less so. We would do some timing tests at this point to quantify the relative speeds of global and "structified" versions. As ALC has pointed out, it is possible we may want to tune the structures. The last vimage step would be to switch on the virtualisatin framework and commit the remainder of the vimage branch (modulo cleanups and what we learn in the mean while). after that I think we turn our attention to the jail sets work that James is doing..