From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lys2r-0005ja-JU for qemu-devel@nongnu.org; Tue, 28 Apr 2009 14:28:41 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lys2m-0005eC-SE for qemu-devel@nongnu.org; Tue, 28 Apr 2009 14:28:41 -0400 Received: from [199.232.76.173] (port=35491 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lys2m-0005ds-Ef for qemu-devel@nongnu.org; Tue, 28 Apr 2009 14:28:36 -0400 Received: from mx20.gnu.org ([199.232.41.8]:46591) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Lys2m-0000E5-6w for qemu-devel@nongnu.org; Tue, 28 Apr 2009 14:28:36 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lys2l-0003Uf-9d for qemu-devel@nongnu.org; Tue, 28 Apr 2009 14:28:35 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Re: [PATCH 9/9] Introduce VLANClientState::cleanup() Date: Tue, 28 Apr 2009 19:28:31 +0100 References: <1239812969-8320-2-git-send-email-markmc@redhat.com> <200904281846.19363.paul@codesourcery.com> <49F74199.5030503@us.ibm.com> In-Reply-To: <49F74199.5030503@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904281928.32369.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Mark McLoughlin , Anthony Liguori , Marcelo Tosatti , Markus Armbruster On Tuesday 28 April 2009, Anthony Liguori wrote: > Paul Brook wrote: > > Hmm, in that case I don't understand your distinction between frontend > > and backend. > > In the case of networking, they don't have to be distinct because all > you need to do is have two "front-ends" and flip the TX/RX queues. > Although even in this case, someone has to own the MAC address so it's > not purely symmetric. I'm still not understanding. Ethernet devices are fundamentally based around a bus architecture. "flip the TX/RX queues" only makes sense if you're talking about a point-point connection. For ethernet devices I see no reason to distinguish between "host" devices (slirp, vde, tap) and "guest" devices. They may be created for different reasons, but they're all doing fundamentally the same thing. > In the general case, that isn't always true for devices. Consider block > devices, for instance. You mean the API we expose to the devices v.s. the API we expose to the image file backends? Or do you mean different layers like ide/scsi v.s. internal block devices? Paul