From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N66vY-0005Io-MV for qemu-devel@nongnu.org; Thu, 05 Nov 2009 13:19:20 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N66vT-0005CQ-MD for qemu-devel@nongnu.org; Thu, 05 Nov 2009 13:19:20 -0500 Received: from [199.232.76.173] (port=41965 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N66vT-0005CG-GW for qemu-devel@nongnu.org; Thu, 05 Nov 2009 13:19:15 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44157) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N66vT-0002Pr-2c for qemu-devel@nongnu.org; Thu, 05 Nov 2009 13:19:15 -0500 Message-ID: <4AF31720.4010303@redhat.com> Date: Thu, 05 Nov 2009 20:19:12 +0200 From: Avi Kivity 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> <4AF2F7E9.50300@us.ibm.com> <4AF2FA2A.4060500@redhat.com> <4AF2FC88.5030303@us.ibm.com> <4AF2FE57.2080700@redhat.com> <4AF30255.2020303@us.ibm.com> In-Reply-To: <4AF30255.2020303@us.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Mark McLoughlin , Arnd Bergmann , Dustin Kirkland , Juan Quintela , qemu-devel@nongnu.org, Michael Tsirkin On 11/05/2009 06:50 PM, Anthony Liguori wrote: >> I'm worrying that we're transforming one problem into two different >> ones. Expanding the scope of qemu, and making it more difficult to >> use advanced networking functionality. > > > Do you object to the idea of having qemu call to a helper program > directly or to the idea of having the helper program in qemu at all? Both, the former much less that the latter. I dislike helper programs, I find them inefficient especially at runtime as the penalties of fork() on a memory hog (esp. one that uses mmu notifiers like qemu+kvm) are considerable. They also make things like the oom-killer a necessity. But I really want qemu out of the security and network management business and focusing on qemulation. Security and network management are the job of the management stack, if they don't do the job well, send patches. > Splitting the helper into a separate project may be a more > constructive discussion as was suggested by Arnd. I agree. > As a separate project, libvirt could also make use of it and use -net > tap,fd= if it wanted to do crazy things. From a distro perspective, > it's just a matter of setting up dependencies to make it Just Work so > I don't object to it that much. It's just a bit annoying to create an > entire new project for a few hundred line helper. I'd much rather see libvirt have a small daemon doing this, but that's my standard dislike of helpers. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.