On 05/01/2012 03:57 PM, Peter Maydell wrote:
On 1 May 2012 21:48, Anthony Liguori<aligu...@us.ibm.com>  wrote:
Legacy properties != static properties.

qdev_add_properties adds both legacy and static properties.  I'm happy to
put static properties into object but not legacy properties.

So, er, how are you defining legacy and static properties?
I would have thought 'legacy property' was 'anything we happen
to already have'...

No, per the naming convention Paolo introduced, it's roughly:

1) legacy properties can be get/set as strings using the qdev parsing methods. Via qdev, they're exposed as -device <type>,<prop-name>=<string>.

In QOM, they're exposed as:

/path/to/device/legacy-<prop-name> = <string>

2) static properties are well-behaved QOM properties that just happen to be defined by the DEFINE_PROP_XXX macros. They use the get/set methods of the property types. New code can (and probably should) make use of static properties.

There's magic in the qdev layer now to decide whether a Property in the array of properties becomes a legacy or static property (it's only ever exposed as one type). When we move static properties to Object, I'd like to keep legacy strictly as a qdev concept so we don't accidentally introduce more legacy properties.

Base classes are free to call object_property_add_static directly and avoid
qdev_add_properties entirely but we need the later for backwards compat.

If qdev_add_properties is purely for back-compat it should be
clearly labelled so we don't use it in new code.

Yes, I expect it would be once we have Paolo's property series in. For now, it's the only real interface we have for adding bulk properties.


Anthony Liguori

-- PMM

Reply via email to