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

[Paul Brook <paul@codesourcery.com>]

> It's multiple inheritance but interfaces (implements) cannot carry state
> which avoids an inheritance diamond problem.

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

Hmm, so how does that work given all of SysbusDevice, PCIDevice and PciBus 
have state?  Making PciBus a separate (composition/shild) object is IMHO not a 
bad thing anyway - I dislike saying that the device and the bus are the same 
thing.  That still leaves both PCIDevice and SysBusDevice state.  The i440fx 
is a fairly simple device, but more complex bridges have additional state that 
needs to be accessible from both the PCI and SysBus interfaces.

Similar examples occur when we have an audio codec with both an i2c command 
interface and an SSI data port.

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

I'm not sure choice is a good thing here!  One of the mistakes I made with 
qdev was to insufficiently document how the device model was supposed to fit 
together.  This resulted in several bastardised qdev "conversions" involving 
gratuitous layering violations.  The end result was that these devices are 
effectively useless as qdev objects, and propagate all the problems that qdev 
was designed to fix.

It would be good to at least have guidelines on how and why the different 
approaches should be used.  Especially for those of us who maybe aren't 
convesant with the more theoretical/academic principles/terminology behind OO 
design.

If it's only a good idea in some cases then you can pretty much guarantee a 
large number of developers will try and use it in the cases where it isn't, 
and vice-versa ;-)

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

Huh? I see absoutely no relationship between piix3 and i8042.
It happens that on the PC machine they are etched into the same piece of 
silicon and one of the i8042 GPIO pins it connected to the A20 gate input, but 
the devices have no actual knowledge of each other.

If you're wanting to provide a convenient way of instantiating common clumps 
of devices then I think that should be separate.  Likewise defining convenient 
machine specific aliases for users.

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

Isn't that the other way around?  The input pin owns the IRQ object, and the 
output pin is the board/machine/user configured reference to that object.

So the link is to an Interface, not a device?  To support multiple instances 
of the same interface we use a closure-like proxy object?
I guess it we assume the number of interface classes is relatively small that 
should work.

Paul