qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2 00/18] qom: dynamic properties and composition tree (v2)
Date: Mon, 05 Dec 2011 09:04:49 -0600	[thread overview]
Message-ID: <4EDCDD91.6010800@codemonkey.ws> (raw)
In-Reply-To: <CAFEAcA_5cztdS40DQLyf9Kp41FkRwkzmg0uoPR=5g8yNC99B8w@mail.gmail.com>

On 12/05/2011 08:50 AM, Peter Maydell wrote:
> On 5 December 2011 14:36, Anthony Liguori<anthony@codemonkey.ws>  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<LSIDevice>(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
>

  reply	other threads:[~2011-12-05 15:05 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-03  0:56 [Qemu-devel] [PATCH v2 00/18] qom: dynamic properties and composition tree (v2) Paolo Bonzini
2011-12-03  2:40 ` Anthony Liguori
2011-12-03 14:24   ` Paolo Bonzini
2011-12-03 21:34     ` Anthony Liguori
2011-12-04 21:01       ` Anthony Liguori
2011-12-05  9:52         ` Paolo Bonzini
2011-12-05 14:36           ` Anthony Liguori
2011-12-05 14:50             ` Peter Maydell
2011-12-05 15:04               ` Anthony Liguori [this message]
2011-12-05 15:33                 ` Peter Maydell
2011-12-05 19:28                   ` Anthony Liguori
2011-12-05 15:47             ` Paolo Bonzini
2011-12-05 16:13               ` Anthony Liguori
2011-12-05 16:29                 ` Paolo Bonzini
2011-12-05 16:38                   ` Anthony Liguori
2011-12-05 17:01                     ` Paolo Bonzini
  -- strict thread matches above, loose matches on Subject: below --
2011-12-02 20:20 Anthony Liguori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EDCDD91.6010800@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).