From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49759) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXuas-0004wM-Im for qemu-devel@nongnu.org; Fri, 25 May 2012 09:30:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SXuam-0004e5-2W for qemu-devel@nongnu.org; Fri, 25 May 2012 09:30:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:15607) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXual-0004bl-R8 for qemu-devel@nongnu.org; Fri, 25 May 2012 09:30:08 -0400 Date: Fri, 25 May 2012 10:30:04 -0300 From: Luiz Capitulino Message-ID: <20120525103004.23cfc4f4@doriath.home> In-Reply-To: <4FBF86E0.7070908@redhat.com> References: <1337882362-20100-1-git-send-email-zwu.kernel@gmail.com> <20120524175321.31254444@doriath.home> <20120525100753.GD30110@stefanha-thinkpad.localdomain> <20120525095313.116f680f@doriath.home> <4FBF822D.9090707@redhat.com> <20120525100746.51d7bf28@doriath.home> <4FBF85BF.6050403@redhat.com> <20120525101830.1793d300@doriath.home> <4FBF86E0.7070908@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Stefan Hajnoczi , kvm@vger.kernel.org, Stefan Hajnoczi , qemu-devel@nongnu.org, Markus Armbruster , zwu.kernel@gmail.com, wuzhy@linux.vnet.ibm.com, jan.kiszka@siemens.com On Fri, 25 May 2012 15:19:28 +0200 Paolo Bonzini wrote: > Il 25/05/2012 15:18, Luiz Capitulino ha scritto: > >> > > >> > Still not sure what you mean... > > I meant it's a similar case. kqemu was a special case and maintenance burden. > > We've dropped it and didn't regret. What's stopping us from doing the same > > thing with vlans? > > That we have an alternative, and that -net dump is actually useful. I haven't reviewed the series yet, but -net dump can work without this, can't it? It's always possible to have alternatives in qemu, the point is how far we're going on bloating it. > >> > we removed kqemu and didn't give an > >> > alternative. This time we are providing an alternative. > > Alternatives already exist, we don't have to provide them. > > Alternatives that require you to have root privileges (anything > involving libvirt or iptables) are not really alternatives. It seems to me that vde doesn't require root, but even if it does, moving this outside of qemu would also be feasible.