From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50523) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXa6F-0007Dr-DP for qemu-devel@nongnu.org; Mon, 05 Dec 2011 10:05:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RXa69-0001IP-Gn for qemu-devel@nongnu.org; Mon, 05 Dec 2011 10:04:59 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:52061) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXa69-0001IH-6d for qemu-devel@nongnu.org; Mon, 05 Dec 2011 10:04:53 -0500 Received: by iakk32 with SMTP id k32so10035694iak.4 for ; Mon, 05 Dec 2011 07:04:52 -0800 (PST) Message-ID: <4EDCDD91.6010800@codemonkey.ws> Date: Mon, 05 Dec 2011 09:04:49 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4ED98C06.5040405@codemonkey.ws> <4EDA3104.8030304@redhat.com> <4EDA95ED.6030706@codemonkey.ws> <4EDBDFC7.3090206@codemonkey.ws> <4EDC946A.3090702@redhat.com> <4EDCD6EA.7090500@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 00/18] qom: dynamic properties and composition tree (v2) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Paolo Bonzini , qemu-devel@nongnu.org On 12/05/2011 08:50 AM, Peter Maydell wrote: > On 5 December 2011 14:36, Anthony Liguori wrote: >> struct LSIDevice { >> PCIDevice parent; >> }; >> >> static void lsi_command_complete(SCSIBus *bus, SCSIRequest *req) >> { >> LSIDevice *dev = LSI_DEVICE(bus); >> ... >> } > > What is the LSI_DEVICE macro actually doing here? I assume > it's not just a cast... https://github.com/aliguori/qemu/blob/qom-next/hw/object.c#L376 It's quite literally dynamic_cast(bus) in C++. >> static void lsi_scsi_bus_initfn(Interface *iface) >> { >> SCSIBus *bus = SCSI_BUS(iface); >> >> bus->command_complete = lsi_command_complete; >> } >> >> TypeInfo lsi_device_info = { >> .name = TYPE_LSI, >> .parent = TYPE_PCI_DEVICE, >> .interfaces = (Interface[]){ >> { >> .name = TYPE_SCSI_BUS, >> .interface_initfn = lsi_scsi_bus_initfn, >> }, { >> } >> }, >> }; >> >> type_register_static(&lsi_device_info); >> >> >>> >>> Perhaps hidden with some macro that lets me just write >>> SCSI_BUS_INTERFACE(dev), but that's the idea; such a lookup function is >>> pretty much what all object models do. GObject has >>> G_TYPE_INSTANCE_GET_INTERFACE, COM/XPCOM has QueryInterface, etc. >>> >>> If I understood everything so far, then here is my question. Are >>> interfaces properties? >> >> >> No. A device is-a interface. Hopefully the above example will make it more >> clear. > > Saying a device is-a interface doesn't match reality. Devices > have multiple interfaces with the rest of the world. There are two ways a device can interact with the rest of the world. It can expose a portion of it's functionality (such as an IRQ) via a child object. This is how it would expose MemoryRegions too. You can take a subset of the exposed children (and perhaps some mapping logic), and for an ad-hoc interface. But sometimes, you want the entire device to act like a specific thing. In this case, you want the LSIDevice to act like SCSIBus. Interfaces are just a more formal form of what would otherwise be an ad-hoc interface. > (This is > one of the major reasons why SysBus exists: it provides a suboptimal > but usuable model of this for the two most common kinds of interface, > MMIO regions and random gpio.) My expectation is that most things that use SysBus today would not implement any interfaces. They would just expose child properties. Regards, Anthony Liguori > -- PMM >