[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC] Plan for moving forward with QOM
Date: Tue, 13 Dec 2011 07:22:05 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13

On 12/12/2011 10:47 PM, Paul Brook wrote:
The full set of devices names and properties used in this example are

   Type: I440FX
   Is-a: Device
   Implements: PciBus
   Name: i440fx
    piix3: Composition<PIIX3>
    slot[1.0]: Backlink<PciDevice>

   Type: PIIX3
   Isa-a: PciDevice
   Implements: IsaBus
   Name: i440fx::piix3
    i8042: Composition<I8042>
    bus: Backlink<PciDevice>  (inherited from PciDevice)

   Type: I8042
   Isa-a: Device
   Implements: Ps2Controller
   Name: i440fx::piix3::i8042
    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
     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
     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
     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 


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]