Re: [Qemu-devel] [PATCH v2 00/18] qom: dynamic properties and composition tree (v2)

[Peter Maydell]

On 5 December 2011 15:04, Anthony Liguori <address@hidden> wrote:
> On 12/05/2011 08:50 AM, Peter Maydell wrote:
>>
>> On 5 December 2011 14:36, Anthony Liguori<address@hidden>  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++.

This is confusing "interface I expose to the world" with
Device. Since "interface I expose to the world shouldn't
be a subtype of Device [they are fundamentally different kinds
of object and having exposed interfaces be kinds-of Devices
is extremely confusing] I'm not sure how this would work.

>> 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.

Perhaps this is terminology confusion again. To me that is 'exposing
an interface to the rest of the world' -- it's a named point where
we expose a specific API. (For an MMIO region probably that's just
"return a MemoryRegion*".)

The other point of confusion here is that "child objects" are doing
two things:
 * composition, ie "my model of the Foo SoC has a child object FooUART
   which implements its serial ports" (but that is an internal
   implementation detail and might change in future)
 * providing connections to the rest of the world, ie "my Foo SoC has
   a child object Pin named 'my_signal' which is part of its API
   contract with the outside world"

Obviously it's useful (and neat) if the implementation of these things
is broadly similar, but I think that because they're conceptually
totally different things we should strive to pick terminology (and
type/class names) that maintain and make clear that difference.

> You can take a subset of the exposed children (and perhaps some mapping
> logic), and for an ad-hoc interface.

This is composition-of-interfaces, right? That would also be useful
(but probably not needed to start with).

> 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 something different again -- it's not just composition-of-interfaces
to provide a SCSI-bus-connector, it's claiming the whole device is-a
SCSI-bus-connector.

I think we should have one way of doing connections between devices,
and we should make sure it does what we want. If we immediately say
"oh, SCSI and PCI connect in a special way" then we've removed a lot
of the impetus to make the standard connection method usefully flexible
and convenient.

>> (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.

Terminology confusion again. They definitely need to be able to expose
the equivalent of gpio in and out pins, and memory regions, by name.

-- PMM