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
