[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: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v2 00/18] qom: dynamic properties and composition tree (v2)
Date: Mon, 05 Dec 2011 16:47:19 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1

On 12/05/2011 03:36 PM, Anthony Liguori wrote:
It's to support method inheritance. In qdev, the various DeviceInfo
structures correspond roughly to the class of the object. When you
create an ISADeviceInfo (the ISA subclass), you declare it statically.

Any methods you aren't overriding are going to be initialized to zero.
You want those methods to inherit their values from the base class. To
do this in qdev, you have to introduce a base-class specific
registration function (isa_qdev_register).

There's not a lot of discipline in how these functions are implemented
and generally makes type registration more complicated as you have to
understand what methods get overridden.

Yeah, that's true. I think in general our class hierarchy is shallow enough that we could live with that, but I appreciate that dynamic initialization has advantages.

links are nullable and usually start out as NULL.

childs are not nullable. I can't really think of a reason why they
should be nullable. What are you thinking here?

Ok, I understand now better what children are.

I've thought a lot about bus properties. I've looked at a lot of code at
this point and for the most part, I think that the reason they even
exist is because we can't inherit a default set of properties.

SCSI is a good example. The bus properties really make more sense as
SCSIDevice properties that are inherited.

Yeah, bus properties *are* most of the time properties that you add to the abstract class, so...

I dislike these properties in the first place, but I'd like to find a
way to convert everything to the QOM type system before we start
rearchitecting how hotplug works.

... just change them to properties on the abstract class.

Perhaps hidden with some macro that lets me just write
SCSI_BUS_INTERFACE(dev), but that's the idea; such a lookup function is
pretty much what all object models do. GObject has

If I understood everything so far, then here is my question. Are
interfaces properties?

No. A device is-a interface. Hopefully the above example will make it
more clear.

No, but I'm confident that there will be a sane way to access the list of interfaces that you embed in the Object type. :)

That's not what I meant. The legacy<> namespace splits the set of QOM
properties in two parts, sane ones and legacy ones. That's wrong,
because the old broken interface remains there. Worse, it remains
there as user-visible API in the JSON etc., and it will remain forever
since we
cannot get rid of -device overnight.

What I suggested is to provide two implementations for each old-style
property: an old string-based one (used for -device etc.) and a modern
visitor-based one (used for qom_*). In other words, old-style
properties would expose both a print/parse legacy interface, and a sane
get/set visitor interface. No need for a legacy<> namespace, because
new-style consumers would not see the old-style string ABI.

Yeah, I'd like to do something like this but I'm in no rush. I agree
that when we declare QOM as a supported interface, we should have
replacements for anything that's in the legacy<> space. That may be from
some magic Property tricks where we introduce Visitor to parse/print or
because we introduce new and improved properties.

Yeah, extending Property looks like a feasible plan. The get/set pair is an adaptor between JSON/Visitor-type data and C struct fields, the parse/print pair is an adaptor between strings and C struct fields.

Maybe now is the right time to rename the legacy properties to all be
prefixed with qdev-? That way we don't need to introduce two different
types for a single property.

Why do you need such a prefix?


reply via email to

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