On 02/20/2012 11:11 AM, Paolo Bonzini wrote:
On 02/19/2012 01:36 PM, Alexander Barabash wrote:
The proposed object_property_get_child() may return either
the direct child with the specified name in the composition tree,
or the value of the link with the specified name, as
object_property_get_link() indeed does.
Have you actually checked that object_property_get_link() doesn't work
for you? It seems to me that your patch does the same as the one-liner:
#define object_property_get_child object_property_get_link
Now _this_ would be good for qemu-trivial. ;)
You are right. Please disregard my v2 patch.
I would only suggest that the documentation of object_property_add_child()
be amended to reflect the fact that the child object may be retrieved using
object_property_get_link().
but does it in a more straightforward way.
I disagree that it is more straightforward. It is more *direct*
perhaps, in that it doesn't go through visitors,
object_get_child_property and object_resolve_path, but it also violates
the encapsulation that properties provide quite heavily.
Peeking at the opaque values of properties should be done as sparingly
as possible. Ideally once, since no QOM property code should be in a
fast path. In this case, it is done in object_resolve_abs_path, and
that should be enough.
Paolo
Alex
