On 07/25/2011 03:44 AM, Anthony Liguori wrote:
Hi,
This series is the rough beginnings of the QEMU Object Model. This is basically
qdev generalized on steroids.
This series includes the core infrastructure, a strawman Device type, and
the beginnings of the conversion of CharDriverState. This is in a rougher
state than I would like it to be but I wanted to get the concepts on the list
as soon as possible.
My plan is to drop the Device parts from future versions of the series and just
focus on backends to start with.
I am not sure of how the Device and Char/Block/NetworkDriver bits relate
to each other. It seems to me that they are two very different families
of objects, and we should treat them differently.
For host devices (Char/Block/Network) we have a relatively simple
interface but we need a richer way to create and destroy the objects at
runtime. We have it already for block and network, we don't for char,
but it is done ad hoc for each hierarchy. We do not have a deep
hierarchy, in fact there is no hierarchy at all (only one abstract class
per subsystem).
Honestly, it is not too bad. It may not be the cleanest code, but is it
worth the kind of ramifications that your patch has? Of course, the
answer could be "yes" if the same model can be applied to devices.
Devices do have the same introspection needs more or less, and I like
your ideas there. However, the requirements are very different in terms
of composition.
Also because there is no hierarchy, composition in host devices can be
done very easily. A decorator for char/block devices, such as a "tee"
device, can treat the wrapped object(s) the same independent of the
actual class. A simple vtable works very well. GObject would also do
well, unifying the introspection at the cost of significantly more
boilerplate.
(Of course, we could rewrite QEMU in Vala).
For *guest* devices, however, this is not the case. The PCI host needs
to know that the device on the other end is a PCI device. Even the
simplest bus, for example I2C, has methods defined on its children.
So, the most important point, it seems to me, is to support composition
effectively. There need not be any hierarchy at all---not even the
two-level hierarchy we have now, everything can inherit from
DeviceState---but the combination between devices must be:
1) in a flexible manner, so that it can express complex topologies (as
long as "plugs" and "sockets" have the same shape of course);
2) in an easily introspectable manner, so that migration and QMP and so
on work very well in the presence of said topologies;
3) in a precise manner, so that the two devices being connected can
interact effectively;
The current qdev fails completely at (1). (2) is very limited if you
consider qdev only; qdev+VMState is at least decent, though nowhere near
the potential of QOM.
However, qdev gets (3) right by making interaction between the parent
and the child go through a bus object that knows the details of both.
In particular, bus objects and their vtable structures are very
effective in qdev because they provide flexibility and avoid impedence
mismatch, with a very limited amount of boilerplate.
By contrast, the plug/socket model in QOM achieves (1) and (2), but in
my opinion it fails at (3). The model for example is not effective in
specifying the properties of the socket, which are roughly are the bus
properties and the fields added by DeviceState abstract subclasses in
the current qdev; it is not clear where they would live in QOM. Perhaps
in the parent device or in an intermediate object between the parent and
the child; if the latter, it looks like a lot of pointer chasing and a
conversion nightmare.
Based on my earlier conversations with Peter, I thought a bit on how to
do more incremental changes to qdev in order to overcome the
inflexibility. Here is a rough overview of the steps:
1) make properties more flexible. In particular, we *absolutely* need
array properties, either static or dynamic. The current special casing
of GPIO pins is required exactly because we do not have arrays of
properties.
Also, since arrays occur a lot in the device state, array properties
would also be required to be able to introspect on run-time properties
(which are now part of VMState only). However, I am not going to
consider run-time introspection much more. It is "a simple matter of
programming" if your general introspection design is done right.
2) add more kinds of first-class (user specifiable) properties. GPIO
pins, for example, which are already part of qdev but cannot be
specified by the user on the command line. Possibly memory regions too.
Anything that can be used to configure a device (with respect to the
main bus or to its parent) should be a property.
3) at this point, you can get rid of the specialties of SysBus devices.
IRQs are an array of GPIO properties, same for memory regions. SysBus
devices can use a naked DeviceState structure.
At this point, many embedded devices could be entirely described in
terms of configuration files, except for legacy options (-serial kind)
and for the few devices that attach directly to the CPU. This without
the need to define artificial buses that do not exist in real hardware.
4) add support for compound properties. A compound properties is such
that you define a property named (coincidence...) "bus" and you get
automatically "bus.parent", "bus.addr", "bus.romfile", "bus.rombar" etc.
5) convert buses to compound properties. Rather than inheriting from
PCIDevice, a PCI device would inherit straight from DeviceState and
include a PCIDevice struct that defines the backlink from a device to
its parent. Note that since we're using C, this is not a big change
from what we're doing now! (Inheritance by containment is a special
case of containment.) And it allows to define very flexibly a device
that would have to sit on two or more buses in the current qdev model.
More importantly, it keeps the effectiveness of the qbus ops model,
while removing the constraint of a tree topology.
It is only when this is done, that we should reconsider introspection
and see if it is useful/sensible to unify the host and guest device
object models.
Because the host models we have now, with all the defects they may have,
*work*. The guest models hardly work for anything but PCs, and even
then only for the subset of devices which are interesting to
hot-plug/unplug. And so it is from them that we should start designing.
Thoughts?
Paolo