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

[Paul Brook <paul@codesourcery.com>]

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

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

What is the difference between "Is-a" and "Implements"? 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.

I'm not so sure we should have Is-a at all.  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.

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.

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>

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>


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