From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NtlLZ-00017N-AA for qemu-devel@nongnu.org; Mon, 22 Mar 2010 13:23:25 -0400 Received: from [199.232.76.173] (port=48440 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NtlLY-000178-SU for qemu-devel@nongnu.org; Mon, 22 Mar 2010 13:23:24 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NtlLW-00062x-AK for qemu-devel@nongnu.org; Mon, 22 Mar 2010 13:23:24 -0400 Received: from mx20.gnu.org ([199.232.41.8]:18098) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NtlLV-0005yn-Sz for qemu-devel@nongnu.org; Mon, 22 Mar 2010 13:23:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NtlLU-0008VH-TO for qemu-devel@nongnu.org; Mon, 22 Mar 2010 13:23:21 -0400 Date: Mon, 22 Mar 2010 19:19:46 +0200 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] Re: [PATCH 0/9] Virtio cleanups Message-ID: <20100322171945.GA19994@redhat.com> References: <4BA786C1.1030105@codemonkey.ws> <20100322151742.GA19675@redhat.com> <201003221551.43559.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201003221551.43559.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org, Juan Quintela On Mon, Mar 22, 2010 at 03:51:43PM +0000, Paul Brook wrote: > > > It's a classic OOP problem. > > > > > > VirtIOBlock is-a VirtIODevice, VirtIODevice is-a DeviceState > > > > > > VirtIOPCI is-a PCIDevice, PCIDevice is-a Device State. > > > > > > But VirtIODevice is-a VirtIOPCI device isn't always true so it can't be > > > an is-a relationship. Initially, this was true and that's why the code > > > was structured that way. Now that we have two type so of virtio > > > transports, we need to change the modelling. It needs to get inverted > > > into a has-a relationship. IOW, VirtIOPCI has-a VirtIODevice. > > > > > > When one device has-a one or more other devices, we model that as a Bus. > > > > Hmm. Is anything wrong with VirtIOPCIBlock which would be both a > > VirtIOBlock and VirtIOPCI device? > > You need to solve multiple inheritance with common (but divergent) ancestors. > > A single device may not have more than one DeviceState. i.e. the DeviceState > that is part of the VirtIOBlock must be the same as the DeviceState that is > part of the PCIDevice. However VirtIOBlock and PCIDevice can not know about > each other or about VirtIOPCIBlock. > > In the current code VirtIOPCIBlock already exists, though only for the > purposes of device creation/configuration. The remainder of the code and data > structures have clean separation between PCI and Virtio code. We can have VirtIOPCIBlock have a single DeviceState. > Anthony's suggestion is that we turn VirtIODevice into a user visible entity > (rather than an implementation detail). This makes the hoist bindings (virtio- > pci.c) completely independent of the virtio backends (e.g. virtio-block.c). > VirtIOPCIBlock ceases to exist, except maybe as a helpful alias to create a > VirtioPCI[Proxy]/VirtioBlock pair. > > > > It's just like SCSI. SCSIDisk is-a SCSIDevice, SCSIDevice is-a > > > DeviceState. > > > > > > LSIState is-a PCIDevice, PCIDevice is-a DeviceState. > > > > > > LSIState has-a SCSIDevice because LSIState implements the SCSIBus > > > interface. > > > > Yes but LSIState emulates a real HBI ... > > Not relevant. There should be nothing magic about virtio. If there is then > we're doing it wrong. > > Paul