qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 03/14] qdev: add qdev_add_properties


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 03/14] qdev: add qdev_add_properties
Date: Tue, 01 May 2012 17:01:01 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 05/01/2012 03:57 PM, Peter Maydell wrote:
On 1 May 2012 21:48, Anthony Liguori<address@hidden>  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





reply via email to

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