From owner-freebsd-virtualization@FreeBSD.ORG Wed Jun 18 15:20:20 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 9F4451065670 for ; Wed, 18 Jun 2008 15:20:20 +0000 (UTC) (envelope-from jamie@gritton.org) Received: from gritton.org (gritton.org [161.58.222.4]) by mx1.freebsd.org (Postfix) with ESMTP id 62C908FC2D for ; Wed, 18 Jun 2008 15:20:20 +0000 (UTC) (envelope-from jamie@gritton.org) Received: from guppy.corp.verio.net (fw.oremut02.us.wh.verio.net [198.65.168.24]) (authenticated bits=0) by gritton.org (8.13.6.20060614/8.13.6) with ESMTP id m5IFKJ92000339; Wed, 18 Jun 2008 09:20:19 -0600 (MDT) Message-ID: <485927AD.8010204@gritton.org> Date: Wed, 18 Jun 2008 09:20:13 -0600 From: James Gritton User-Agent: Thunderbird 2.0.0.9 (X11/20080228) MIME-Version: 1.0 To: freebsd-virtualization@freebsd.org References: <48588595.7020709@gritton.org> <200806181619.07026.zec@icir.org> In-Reply-To: <200806181619.07026.zec@icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on gritton.org X-Virus-Status: Clean Cc: Subject: Re: V_* meta-symbols and locking 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: Wed, 18 Jun 2008 15:20:20 -0000 Marko Zec wrote: > You are most probably right about the current code not sufficiently > protecting the "hostname" global from concurrent access, but I don't > see how V_ macroization / virtualization adds or changes anything to > this particular issue. The change is that with the virtual hostname, I want to have the locking that is currently lacking. As that locking would be in a jail context, it doesn't make sense to go use these virtual-variable macros when the "jailness" of it is explicitly exposed anyway. > The same goes for virtualizing the networking > state - if there is a locking issue in a newtorking subsystem, > virtualization should not make such issues any more or less pronounced. I suspect most, perhaps all, of the networking variables will work with their own locking, especially if the locks themselves are part of a virtualized structure. - Jamie