From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NtsJY-0005Dd-3V for qemu-devel@nongnu.org; Mon, 22 Mar 2010 20:49:48 -0400 Received: from [199.232.76.173] (port=51334 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NtsJW-0005DV-Q3 for qemu-devel@nongnu.org; Mon, 22 Mar 2010 20:49:46 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NtsJW-0004oc-2H for qemu-devel@nongnu.org; Mon, 22 Mar 2010 20:49:46 -0400 Received: from mx20.gnu.org ([199.232.41.8]:21565) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NtsJV-0004oY-RM for qemu-devel@nongnu.org; Mon, 22 Mar 2010 20:49:45 -0400 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NtsJU-0008AF-SP for qemu-devel@nongnu.org; Mon, 22 Mar 2010 20:49:45 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Re: [PATCH 0/9] Virtio cleanups Date: Tue, 23 Mar 2010 00:49:41 +0000 References: <20100322171945.GA19994@redhat.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003230049.41271.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: "Michael S. Tsirkin" , Juan Quintela >Solutions: >- VirtIOPCIBus and hang devices from there (anthony). Why? because > this is a simulated pci bus, we can implement the features that we > need (not full pci) in the three showed architectures. We will have > VirtIOPCIBLock everywhere, and its VirtIOPCIBus implmentation will > hide the details. This is not how I understood Anthony's proposal. VirtIOPCIBus makes no sense. The whole reason we have this problem is because the VirtIO devices can not make any assumptions about the bus they are connected to. The key point is that we promote VirtIO devices to nodes in the device tree. i.e. VirtIODevice descends directly from DeviceState. Instead of trying to make a single polymorphic hybryd object, split into separate objects for the component parts. Each host binding (PCI, syborg, s390, etc.) provides a single VirtIO bridge device. This includes a VirtIOBus, to which the VirtIODevice is attached. Most of the code and abstraction layers for this are already there. We just replace virtio_bind_device with VirtIOBus, add direct registration of VirtIODevice, and rip out all the crufty old device specific bits from virtio- pci.c. > - having multiple inheritance is "more natural" to virtio, then we have > to change all the system to be able to allow multiple inherintance, > even if it is more complex, and nothing else uses/needs it (mst). I'm not convinced multiple inheritance solves the real problem, much less that it is worthwhile. Paul