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.
Regards,
Anthony Liguori
-- PMM
