From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1N64LG-0005BF-6z
	for qemu-devel@nongnu.org; Thu, 05 Nov 2009 10:33:42 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1N64LB-00056k-6q
	for qemu-devel@nongnu.org; Thu, 05 Nov 2009 10:33:41 -0500
Received: from [199.232.76.173] (port=41327 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1N64LA-00056S-OG
	for qemu-devel@nongnu.org; Thu, 05 Nov 2009 10:33:36 -0500
Received: from mx1.redhat.com ([209.132.183.28]:16126)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1N64LA-0007tl-A3
	for qemu-devel@nongnu.org; Thu, 05 Nov 2009 10:33:36 -0500
Message-ID: <4AF2F04B.8050105@redhat.com>
Date: Thu, 05 Nov 2009 17:33:31 +0200
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support
	for qemu
References: <1257294485-27015-1-git-send-email-aliguori@us.ibm.com>
	<4AF2E247.3090409@redhat.com> <4AF2E7CE.8010506@us.ibm.com>
	<4AF2EB17.8090202@redhat.com>
In-Reply-To: <4AF2EB17.8090202@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: Mark McLoughlin <markmc@redhat.com>, Arnd Bergmann <arndbergmann@googlemail.com>, Dustin Kirkland <kirkland@canonical.com>, Juan Quintela <quintela@redhat.com>, qemu-devel@nongnu.org, Michael Tsirkin <mst@redhat.com>

On 11/05/2009 05:11 PM, Avi Kivity wrote:
> But we're forcing our style of security management on them.  How to 
> store permissions is the management system's job (and for a clu^Houd, 
> it will typically be stored in a central database, not be scattered 
> around /etc).
>
> Again, IMO we should stick to making a guest work, and leave all the 
> glue to management.
>

As an example of why this is so, if the management stack wants to 
configure the tap interface further (say, add some ebtables rules 
guarding the new interface) it must push this into qemu or stop using 
-net bridge.

Having the tap accessible to management also allows it to run tcpdump or 
collect statistics on it at runtime.

-- 
error compiling committee.c: too many arguments to function