From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50454) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SYzx9-0008On-Mm for qemu-devel@nongnu.org; Mon, 28 May 2012 09:25:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SYzx5-0003qJ-4h for qemu-devel@nongnu.org; Mon, 28 May 2012 09:25:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45195) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SYzx4-0003qC-Ro for qemu-devel@nongnu.org; Mon, 28 May 2012 09:25:39 -0400 Date: Mon, 28 May 2012 10:25:51 -0300 From: Luiz Capitulino Message-ID: <20120528102551.2ffce963@doriath.home> In-Reply-To: <20120528111704.GD30438@stefanha-thinkpad.localdomain> References: <4FBF822D.9090707@redhat.com> <20120525100746.51d7bf28@doriath.home> <4FBF85BF.6050403@redhat.com> <20120525101830.1793d300@doriath.home> <4FBF86E0.7070908@redhat.com> <20120525103004.23cfc4f4@doriath.home> <4FBF8B0B.1090601@redhat.com> <20120525104322.2da0b0ba@doriath.home> <4FBF8D70.1030304@redhat.com> <20120525105628.1a1f3f8d@doriath.home> <20120528111704.GD30438@stefanha-thinkpad.localdomain> 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: Stefan Hajnoczi Cc: kvm@vger.kernel.org, jan.kiszka@siemens.com, qemu-devel@nongnu.org, Markus Armbruster , zwu.kernel@gmail.com, wuzhy@linux.vnet.ibm.com, Stefan Hajnoczi , Paolo Bonzini On Mon, 28 May 2012 12:17:04 +0100 Stefan Hajnoczi wrote: > What we need to decide is whether it's okay to drop QEMU "VLANs" > completely and change dump command-line syntax? I'd vote for dropping it. > I think vlan-hub doesn't hurt anyone because the code has been isolated > and we keep backwards compatibility. So I'd personally still go the > vlan-hub route for QEMU 1.x. Just to make it clear: I'm not against this series. I'm against having the functionality in qemu. If we want to keep the functionality, then I completely agree that this series is the way to go. Having glanced at this series I think it's beyond comparison with the current code...