From owner-freebsd-virtualization@FreeBSD.ORG Thu Sep 4 19:53:47 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 D90031065675 for ; Thu, 4 Sep 2008 19:53:47 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outA.internet-mail-service.net (outa.internet-mail-service.net [216.240.47.224]) by mx1.freebsd.org (Postfix) with ESMTP id 496628FC15 for ; Thu, 4 Sep 2008 19:53:47 +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 1A983248C; Thu, 4 Sep 2008 12:53:47 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id C20472D6010; Thu, 4 Sep 2008 12:53:46 -0700 (PDT) Message-ID: <48C03CD1.3010908@elischer.org> Date: Thu, 04 Sep 2008 12:53:53 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Brooks Davis References: <48C03A8B.4050607@elischer.org> <20080904195031.GB4117@lor.one-eyed-alien.net> In-Reply-To: <20080904195031.GB4117@lor.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD virtualization mailing list Subject: Re: next vimage commit.. a comment 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: Thu, 04 Sep 2008 19:53:47 -0000 Brooks Davis wrote: > On Thu, Sep 04, 2008 at 12:44:11PM -0700, Julian Elischer wrote: >> Some have suggested that we change the VNET_ITERLOOP_BEGIN() / >> VNET_ITERLOOP_END() code, >> and thinking about this I suggest that we go straight for the >> final solution of: >> >> change: >> code >> code >> code >> >> to: >> >> FOREACH_VNET(VINET, vnet_inet) { >> code >> code >> code >> } >> >> straight away. and get it over and done with... >> >> anyone have thoughts? > > I agree. We should avoid committing new code we plan to rip up later. > > -- Brooks Ok well it's going to massively expand the size of this commit diff but if we are convinced that we will "understand" that it does nothing (yet) then we can still review it for "no binary changes" relatively easily once this happens..