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

[Paul Brook <paul_brook@mentor.com>]

> > Do we have a user interface issue here?
> 
> I want to separate backwards compatibility from ABI compatibility.  We
> should provide nice high level interfaces that are forever backwards
> compatible.  But when it comes to hooking up IRQs between devices, that
> interface should just be ABI compatible, not necessarily backwards
> compatible.
> 
> To achieve ABI compatibility, we just have to be strict about renaming
> types if they change significantly and introducing new field names instead
> of changing the semantics of existing fields.

Relying on type to disambiguate between different links to an object while 
only allowing one of those types to be stateful make using a single object to 
implement logically distinct functionality (e.g. Device v.s. Bus, or different 
types of device interface) is a user visible implementation detail.

In practice we really do want to inherit state (which presumably includes 
properties) from multiple classes.  I'd be amazed if we last many releases 
without breaking machine descriptions and/or the "qemu -device blah" because 
of this.

I haven't worked out the details, maybe we need a "Self" property, plus a 
policy of never having user visible stuff link to an primary device node.
If the primary object happens to implement/inherit from that Interface then it 
sets the property to itself.  Otherwise it creates a stateful bus object 
(maybe using composition).

This allows you to have i440fx implement PciBus directly when it's convenient, 
but the board description always attaches devices to ::i440x::pcibus.

I think I'm starting to see now why Java code is often a twisty mess of 
interfaces and adaptors.

> >>> I don't see how this can work without a closure object.  We need a
> >>> central device that is capable of recieving signals from many client
> >>> devices.  Those client devices don't know where they are, they just
> >>> shout down a point-point link. I'd say this is a fairly common
> >>> topology.
> >>> 
> >>> If the central device implements that point-point interface directly
> >>> then it has no idea which device is talking to it.  We need to create
> >>> child objects with a port ID property and implementing the p-p
> >>> interface, then bind each client device to one of these child objects.
> >>>  The child objects can't do anything useful on their own, so need to
> >>> proxy the signal to an interface on the main object, adding in their
> >>> port id.
> >> 
> >> If you aren't using inheritance, yes, you need to pass closures to the
> >> child objects.  I dislike that kind of proxy modeling.
> > 
> > How would you solve this using inheritance?
> > 
> > I can see how it works when the device knows its address, but it seems
> > kinda lame to tell a device "You have a dedicated communication channel.
> >  But I'm lazy and will smush them all together.  Please add this
> > additional token to every signal you send".
> 
> Yes, adding a token is how you would have to do it.

Ugh. Except it's worse than I thought.  That token has to come from the user.  
Either via some arbitrary property on the client device, which is going to be 
different for every device especially when a device can link to multiple 
interfaces of the same class.  Or we need some mechanism for attaching data to 
a link, rather than just conecting the two interfaces together.  Neither of 
which sound desirable.

There's also the issue that the token itsef is device specific.  Identifying 
physical incarnations of logically independent interfaces is well outside the 
scome of the relevant bus, and varies from device to device. e.g. one 
interrupt controller mugh device to label its pins A-P, or 0-16, or 128-144, 
or "alice"/"bob".

Paul