[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 00/18] qom: dynamic properties and compositio

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH v2 00/18] qom: dynamic properties and composition tree (v2)
Date: Sat, 03 Dec 2011 15:34:37 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13

On 12/03/2011 08:24 AM, Paolo Bonzini wrote:
On 12/03/2011 03:40 AM, Anthony Liguori wrote:
That is still true. The next step, inheritance, will pull the properties
into a base class. That base class can be used elsewhere outside of the
device model.

But this is already a 20 patch series. If you want all of that in one
series, it's going to be 100 patches that are not terribly easy to
review at once.

Without a design document and a roadmap, however, it's impossible to try to
understand how the pieces will be together. 100 patches may require some time to
digest, but 20 patches require a crystal ball to figure out what's ahead.

You can see a bit further by looking at:


That fills out the composition tree pretty well for the pc. The next step is aggressive refactoring such that the qdev objects reflect the composition. IOW, we should create the rtc from within the piix3 initialization function.

But before we can do that, we need to split construction and introduce realize which requires inheritance.

So I'd like to fill out the composition tree next (HEAD~2 in that branch, but split up nicely). Having a flushed out composition tree really helps figure out what the code should look like and my hope is that other platforms can start refactoring too.

Inheritance is not terribly hard. First step is adding a type pointer to DeviceState *, and then introducing some dynamic_cast-like macros and then touching every file to use them.

Second step is QOM-style methods and polymorphism.  That's not terribly hard 

Once we have that, we can do realize.

Note that I haven't really talked about busses. I do want to get rid of qdev busses but I'm in no rush at all. We can do 95% of the necessary refactoring without touching busses and hot plug and I think that's the right strategy.

Make sure that all required abstractions can be implemented in
terms of a QOM composition tree.

Not composition tree, you mean via the link graph.

I mean both, but the link graph is already understandable (1-to-1 is easy).
Right now I can hardly understand how the composition tree will work, for
example: how do you constrain children to be subclasses of some class (or to
implement some interface)?

Composition never involves subclasses. The tree I point you to above is about as complete as it can be right now without doing more qdev conversions. It should answer all of your questions re: composition.

2) Related to this, you have a lot of nice infrastructure, but (unlike
what you did with QAPI) you haven't provided yet a clear plan for how
to get rid of the old code. You also have only very limited uses of
the infrastructure (see above).

Old style properties go away as they're converted to new style properties.

And how do they? How much code churn does that entail, in the devices and in
general? In fact, why do they need conversion at all? Static properties are
special enough to warrant something special.

They can stay around forever (or until someone needs non-static properties) but I strongly suspect that we'll get rid of most of them as part of refactoring.

An awful lot of properties deal with connecting to back ends and/or bus addressing. None of that will be needed anymore.

If you want to see how this all is going to look, look at the old tree
:-) That's where we're going to end up.

Let's write documentation on that already.

I have written lots of documentation. Just take a look at the wiki. Nothing speaks better than code.

It's better for various reasons--type safety and ease of use--even if
it costs some boilerplate. For example the child property should be
as simple as

+struct ChildDeviceProperty {
+ DeviceProperty prop;
+ DeviceState *child;
+struct DevicePropertyInfo child_device_property_info = {
+ .size = sizeof(ChildDeviceProperty);
+ .get = qdev_get_child_property,
void qdev_property_add_child(DeviceState *dev, const char *name,
DeviceState *child, Error **errp)
gchar *type;

type = g_strdup_printf("child<%s>", child->info->name);

- qdev_property_add(dev, name, type, qdev_get_child_property,
- NULL, NULL, child, errp);
+ prop = (ChildDeviceProperty *)
+ qdev_property_add(&child_device_property_info,
+ dev, name, type, errp);
+ /* TODO: check errp, if it is NULL -> return immediately. */
+ prop->child = child;

This seems quite a bit uglier to me.

I did say it costs some boilerplate, but it's once per type and you said there's
a dozen of those. The type safety and more flexibility (an arbitrary struct for
subclasses rather than an opaque pointer) is worth the ugliness.

I disagree. Take a look at how string properties work in the above tree. It's strongly type safe. My old qom tree builds properties based on code generation too so the whole discussion on safety is somewhat moot.

I think also that the type should not be part of DeviceProperty.
Instead it should be defined by subclasses, with the
DevicePropertyInfo providing a function to format the type to a

I don't really know what you mean by this.

Once the type is written as child<RTCState>, you've lost all info on it. Each
property type should have its own representation for types (it can be implicit,
or it can be an enum, or it can be a DeviceInfo), with a method to pretty-print 

I don't know what you mean by "lost all info on it" but I'm strongly opposed to a "pretty-print" method. Having the pretty printing information in the type is almost never what you want.

We jump too quickly at
doing conversions without thinking through the underlying interface.

I hoped you had thought it through. ;)

I have :-) But I take your position as arguing that we should convert half the tree before merging anything which I disagree with.

You may find it odd to hear me say this, but I grow weary of adding too
much class hierarchy and inheritance with properties. Yes, we could make
it very sophisticated but in practice it doesn't have to be. Properties
should be one of two things: primitive types or link/childs.

... and interfaces. Accessing them by name as a property should work well.

No, not interfaces.  The object *is-a* interface.  It doesn't has-a interface.

We've gone through this debate multiple times. As I said above, we really don't need to even worry about this until most of the work is done so let's avoid this debate for now. The property infrastructure is flexible enough to support both models.

This is where qdev goes very wrong. It mixes up user interface details
(how to format an integer on the command line) with implementation
details. There's no reason we should be indicating whether a property
should be display in hex or decimal in the device itself.

That's totally true. But there's no reason why qdev properties cannot be split
in two parts, a sane one and a legacy one.

Bingo! Hence, the 'legacy<>' namespace. If you want to do a declare, struct member based syntax that encodes/decodes as primitive types to a Visitor, be my guest :-)

I don't think it's usually what we want, but I'm not opposed to it.

For artificial properties you would need one-off classes; but you can
still provide a helper that creates a specialized
DeviceProperty+DevicePropertyInfo from the functions. I'm thinking of
how people implement prototype-based OO on top of class-based OO, but
it might be just a macro.

I think you're over thinking the problem. There are going to be maybe a
dozen property types and that's it. They all with correspond exactly to
C types with the exception of links/children.

I was thinking of one-off types such as rtc's struct tm.

I'd really like to get to a point where these type visitors were being 


Anthony Liguori

reply via email to

[Prev in Thread] Current Thread [Next in Thread]