Re: [Qemu-devel] [RFC] Plan for moving forward with QOM

[Anthony Liguori <anthony@codemonkey.ws>]

On 12/12/2011 10:47 PM, Paul Brook wrote:
>> The full set of devices names and properties used in this example are
>> below:
>>
>>    Type: I440FX
>>    Is-a: Device
>>    Implements: PciBus
>>    Name: i440fx
>>    Properties:
>>     piix3: Composition<PIIX3>
>>     slot[1.0]: Backlink<PciDevice>
>>
>>    Type: PIIX3
>>    Isa-a: PciDevice
>>    Implements: IsaBus
>>    Name: i440fx::piix3
>>    Properties:
>>     i8042: Composition<I8042>
>>     bus: Backlink<PciDevice>  (inherited from PciDevice)
>>
>>    Type: I8042
>>    Isa-a: Device
>>    Implements: Ps2Controller
>>    Name: i440fx::piix3::i8042
>>    Properties:
>>     aux: Backlink<Ps2Mouse>
>
> I haven't looks at the patches in detail, but your description looks fairly
> dubious in its current form.

This is an old thread.  A few things have evolved since then.

>
> Is the type of piix3::bus a typo? I think this should be Backlink<PciBus>.

Yup.  It's now link<PciBus>.

>
> What is the difference between "Is-a" and "Implements"?

It's multiple inheritance but interfaces (implements) cannot carry state which 
avoids an inheritance diamond problem.  This is the inheritance model used by 
Java, C#, and glib.

> It sounds like some
> form of multiple inheritance, but it's unclear to me which should be the
> primary type.  For PCI host bridges like the i440fx we currently have to split
> them into two, one fot the host bus and the other for the PCI bus.  It feels
> like if we design the model properly this should no longer be necessary.

Yes, that's exactly what this solves.  I think we could probably make i440fx 
is-a PCIDevice that implements a PciBus.  It's the same thing we would do with a 
PCI Bridge.

> I'm not so sure we should have Is-a at all.

A point that has been repeatedly brought up is that you can avoid primary 
inheritance and just rely on composition using composed interfaces as your 
communication vehicle.

I think in some cases, that will make sense, and the object model allows that.

> Isn't the point of replacing the
> bus/device hierachy with a set of links that devices don't follow a simple
> tree structure?  It's fairly common for the tree branches to merge back
> together when a single device communicates via multiple busses.

Yes, but don't confuse the inheritance tree with the device graph.

> It's somewhat unlear what the purpose of composition is.  Using composition
> for piix4::piiix and piix3::i8042 seems wrong.  In fact piix3 shouldn't have
> any knowledge of i8042 at all, it's just annother random ISA device.

i8042 is not a random ISA device.  It lives in the piix3 and the piix3 has 
intimate knowledge of it.  When model a20 line propagation, this is actually an 
important detail.

> Speaking of which, presumably i8042 should be an IsaDevice, which inherits
> (amongst other things) a bus: Backlink<IsaBus>  property.
>
> What happens when my device has multiple parts that need to be referred to by
> other devices?  An interrupt controller is the most obvious example, but
> similar issues occur for any device that has multiple connections of the same
> type.  Am I expected to create a whole bunch of dummy devices and a private
> interface to bounce everything back to the main device, somethig like:
>
> Type: MagicInterruptController
>    Is-a: SystemBusDevice
>    Implements: MagicInterruptInterface
>    Properties:
>      in_pin0: Composition<MagicInterruptPin, pin_number=0, controller=this>
>      in_pin1: Composition<MagicInterruptPin, pin_number=1, controller=this>
>      out_pin: link<IRQ>


No, there would be a single 'Pin' class that would be used for irqs.  There is 
no need to subclass it.

>
> Type: MagicInterruptPin
>    Implements: IRQ
>    Properties:
>      pin_number: int
>      controller: BackLink<MagicInterruptInterface>
>
> It seems like rather than having a device implement a set of interfaces, it
> might be better to have these be properties.  Call them a Target<>.  The above
> then becomes something like:
>
> Type: MagicInterruptController
>    Is-a: SystemBusDevice
>    Properties:
>      in_pin0: Target<IRQ>
>      in_pin1: Target<IRQ>
>      out_pin: Link<IRQ>

So this is more like how it works today except s/Link/child/ and s/Target/link/g.

Regards,

Anthony Liguori

>
> Where the Target<>  properties are objects/methods provided by the device, and
> the Link<>  properties are pointed to them as the machine is constructed.
>
> Paul
>