From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47813) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Td22n-0003r1-OW for qemu-devel@nongnu.org; Mon, 26 Nov 2012 12:00:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Td22b-0002GM-DF for qemu-devel@nongnu.org; Mon, 26 Nov 2012 12:00:29 -0500 Received: from e28smtp04.in.ibm.com ([122.248.162.4]:42083) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Td22a-00021t-Po for qemu-devel@nongnu.org; Mon, 26 Nov 2012 12:00:17 -0500 Received: from /spool/local by e28smtp04.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 26 Nov 2012 22:29:59 +0530 Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66]) by d28relay04.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qAQGxvrZ5898672 for ; Mon, 26 Nov 2012 22:29:57 +0530 Received: from d28av04.in.ibm.com (loopback [127.0.0.1]) by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qAQMTmtJ002820 for ; Tue, 27 Nov 2012 09:29:48 +1100 From: Anthony Liguori In-Reply-To: References: <1353595852-30776-1-git-send-email-fred.konrad@greensocs.com> <1353595852-30776-2-git-send-email-fred.konrad@greensocs.com> <87k3t8qvrg.fsf@codemonkey.ws> Date: Mon, 26 Nov 2012 10:59:16 -0600 Message-ID: <877gp8pafv.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [RFC PATCH v2 1/3] virtio-bus : Introduce VirtioBus. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: e.voevodin@samsung.com, mark.burton@greensocs.com, qemu-devel@nongnu.org, stefanha@redhat.com, cornelia.huck@de.ibm.com, afaerber@suse.de, fred.konrad@greensocs.com Peter Maydell writes: > On 26 November 2012 14:33, Anthony Liguori wrote: >> VirtioBusInfo is not a great name. This is a proxy class that allows >> for a device to implement the virtio bus interface. >> >> This could be done as an interface but since nothing else uses >> interfaces, I'm okay with something like this. But the first argument >> ought to be an opaque for all methods. > > We have at least one user of Interface in the tree IIRC. > I'd much rather we did this the right way -- the only reason > it's the way Fred has coded it is that there's no obvious > body of code in the tree to copy, so we're thrashing around > a bit. If you tell us what the correct set of structs/classes/ > interfaces/etc is then we can implement it :-) I really think extending virtio-bus to a virtio-pci-bus and then initializing it with a link to the PCI device is the best approach. It's by far the simpliest approach in terms of coding. Did I explain it adequately? To recap: virtio-bus extends bus-state - implements everything that VirtIOBindings implements as methods virtio-pci-bus extends virtio-bus - is constructed with a pointer to a PCIDevice - implements the methods necessary to be a virtio bus virtio-device extends device-state - implements methods used by virtio-bus Regards, Anthony Liguori > > -- PMM