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

[Anthony Liguori <anthony@codemonkey.ws>]

On 12/15/2011 12:59 PM, Paul Brook wrote:
>>> 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.

But there are two distinct classes of user.  One class of user really is thinking:

"I want a KVM virtual machine, with 3 disks and 2 network cards"

They could give a flying hoot whether the i440fx inherits from pcidevice or 
implements pcibus.

We need to provide an obviously distinct UI and API for these users.  The vast 
majority of command line users fall into this category.  And once this user 
learns how do create a guest with 3 disks and 2 network cards, they should never 
have to learn another way of doing it.

There is a second class of "user" that is doing very sophisticated things and 
cares about this information.  But this sophisticated user (i.e. libvirt) wants 
to be able to probe QEMU to understand what features are available because it 
very likely is evolving just as quickly as QEMU is.

For this user, it's more import to provide this introspection interface than it 
is to guarantee that we never add/remove devices and interfaces.  We can be 
flexible with this class of user provided they have clear and obvious ways to 
figure out what we're doing.

> In practice we really do want to inherit state (which presumably includes
> properties) from multiple classes.

I think before we can declare something "in practice", we have to actually 
experience it, in practice :-)

Object oriented design is not an exact science.  There is no Right Way to model 
things because all models are lossy in some way.  We can debate the merits of MI 
verses SI w/interfaces literally for years but there's enough existence proof 
out there that with SI w/interfaces, you can build complex systems.

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

You're advocating only connecting properties to properties, and never an object 
to a property?  I think that's needlessly complicated.  In the vast majority of 
cases, you just case about saying "connect this CharDriverState to this Serial 
device".  We should make it much more complicated than that.

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

Java is a pure OO language.  There is no such thing as a free standing function. 
  As a result, there are numerous things that are very complicated because 
things that you would naturally express as a function end up being expressed as 
an Adaptor class or something like that.

Just about anything taken to it's logical extreme is bad..

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

But this entire use-case seems to be synthetic.  Do you have a real case where 
you would want to inherit twice from the same interface?

Regards,

Anthony Liguori

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